DETAILED ACTION
This action is in response to a filing filed on November 8th, 2024. Claims 1-10 and 12 are amended and claim 11 is cancelled. Claims 1-10 and 12 have been examined in this application.
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 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-10 and 12 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e. an abstract idea) without significantly more.
Step 1: Claims 1-9 is/are drawn to method (i.e., a process), and claims 10 is/are drawn to system (i.e., a manufacture), and claims 12 is/are drawn to computer readable storage medium (i.e., a manufacture). (Step 1: YES).
Step 2A - Prong One: In prong one of step 2A, the claim(s) is/are analyzed to evaluate whether it/they recite(s) a judicial exception.
Claim 1: Computer implemented method for processing a Raffle Sale, comprising the steps of: putting on sale, by a Merchant, of a product and/or a service via a Raffle Sale, wherein a number of selected Winners from a group of Raffle Sale participants receive the right to purchase said product and/or service,
defining, by the Merchant, criteria for the selection of Winners from a group of Raffle Sale participants,
requesting, by a User, to be added to the group of Raffle Sale participants and presenting, by said User, a PAN primary account number (PAN) as payment method,
receiving, by the Merchant, the request of the User to be added to the group of Raffle participants and the PAN related with the User,
sending, by the Merchant, the PAN of the User as a participant to the Raffle Sale, to a Financial Institution, responsible for the payment processing of payments linked with the PAN,
receiving, by the Financial Institution, the PAN of the User and adding the User to a group of Raffle Sale participants,
applying, by the Financial Institution, the criteria for the selection of Winners from the group of Raffle Sale participants to select a number of Winners,
sending, by the Financial Institution, a list of selected Winners to the Merchant,
receiving, by the Merchant, the list of selected Winners of the Raffle Sale, and
informing, by the Merchant, the selected Winners and processing the payment of the product and/or service for the selected Winners.
(Examiner notes: The underlined claim terms above are interpreted as additional elements beyond the abstract idea and are further analyzed under Step 2A - Prong Two)
Under their broadest reasonable interpretation, the independent claims is/are directed to the abstract idea of organizing human activity involving conducting a raffle-based sales promotion and determining winners based on participant information associated with payment accounts. The method recites receiving a request from users to participate in a raffle sale, collecting primary account number (PAN), applying selection criteria to determine winners, and notifying winners and processing payments. These steps correspond to fundamental commercial practices involving marketing promotions, lotteries, and sales transactions. The recited steps merely collect information, analyze the information according to defined criteria, and communicate results of the selection process, which are activities that can be performed as part of organizing commercial promotional events. Further the claim describes a fundamental economic practice involving conducting a raffle sale and selecting winners from participants using payment information (i.e. the steps of receiving participation requests, collecting primary account number, selecting winners according to criteria, and notifying winners) represent organizing human activity related to commercial transactions and promotional raffles. These activities could be performed mentally or using pen-and-paper methods, such as collecting entries, recording participant payment information, randomly selecting winners, and notifying participants. From applicant’s specification, the claimed invention is implemented to “the criteria for selecting Winners from a group of Raffle Sale participants comprises defining criteria for the selection of Winners, based on historic payment data, linked with a PAN. This means that the Merchant prefers to use criteria that are linked to the historic payment data linked to a PAN that is presented by the User to identify as a Raffle participant and as a payment method” (see 0068-0076 of instant specification). The claims recite a method of organizing human activity, specifically steps of recites an offer grading model, offer negotiation server, and user interface represents generic computer implementation of this commercial advisory process and does not integrate the abstract idea into a practical technological improvement. The Examiner notes that although the claim limitations are summarized, the analysis regarding subject matter eligibility considers the entirety of the claim and all of the claim elements individually, as a whole, and in ordered combination.
The dependent claims 2-9 do not add subject matter that meaningfully limits the abstract idea. Claim 2 recites confirming receipt of a request to participate in the raffle. This step merely involves communicating acknowledgement information. Claim 3 recites defining random-based selection criteria. This step involves mathematical or statistical techniques used to select winners, which represents an abstract concept involving the application of mathematical relationships. Claims 4 and 8 recite using historic payment data linked to payment accounts and comparing consumer profile information with defined criteria to determine winners. These steps involve collecting and analyzing financial transaction data associated with payment accounts, which represents data analysis used to support commercial decision making. Claim 5 recites adding an anonymized identifier to a primary account number to generate a raffle identifier. This step involves organizing and labeling data using identifiers, which is a form of data manipulation and information organization. Claims 6 and 7 recite retrieving consumer information from databases containing financial transaction data and generating consumer profiles linked to payment accounts. These steps involve collecting and analyzing information about consumers for commercial purposes, which is a form of data gathering and analysis related to marketing and financial services. Claim 9 recites informing participants who were not selected as winners. This step merely involves communicating results of the raffle selection, which represents insignificant post-solution activity involving information transmission. None of the dependent claims recite a specific improvement to computer functionality, a new data structure, or a particular technical solution beyond the abstract data analysis and recommendation concept. Accordingly, the recited computer and server components are generic technological implementations of the abstract process rather than improvements to the underlying technological infrastructure, and the claimed steps represent the fundamental concept of evaluating and advising on real estate offers which is/are directed to the same abstract idea as independent claims and do not add significantly more., which falls within a judicial exception under 35 U.S.C. §101.
Independent claim(s) 10 and 12 recite/describe nearly identical steps (and therefore also recite limitations that fall within this subject matter grouping of abstract ideas), and this/these claim(s) is/are therefore determined to recite an abstract idea under the same analysis.
As such, the Examiner concludes that claims 1 recites an abstract idea (Step 2A – Prong One: YES).
Step 2A - Prong Two: In prong two of step 2A, an evaluation is made whether a claim recites any additional element, or combination of additional elements, that integrate the exception into a practical application of that exception. An “addition element” is an element that is recited in the claim in addition to (beyond) the judicial exception (i.e., an element/limitation that sets forth an abstract idea is not an additional element). The phrase “integration into a practical application” is defined as requiring an additional element or a combination of additional elements in the claim to apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that it is more than a drafting effort designed to monopolize the exception.
The requirement to execute the claimed steps/functions using a computer, a processor, a Merchant, a User, a Financial Institution, etc. (Claims 1, 10, and 12) is/are equivalent to adding the words “apply it” on a generic computer and/or mere instructions to implement the abstract idea on a generic computer.
Similarly, the limitations of using a computer, a processor, a Merchant, a User, a Financial Institution, etc. (Claims 1, 10, and 12, and dependent claims 2-9) are recited at a high level of generality and amount to no more than mere instructions to apply the exception using generic computer components. This/these limitation(s) do/does not impose any meaningful limits on practicing the abstract idea, and therefore do/does not integrate the abstract idea into a practical application (see MPEP 2106.05(f)).
Further, the additional limitations beyond the abstract idea identified above, serves merely to generally link the use of the judicial exception to a particular technological environment or field of use. Specifically, it/they serve(s) to limit the application of the abstract idea to computerized environments (e.g., put, define, request, receive, send, apply, inform, etc. steps performed by a computer, a processor, a Merchant, a User, a Financial Institution, etc.). This reasoning was demonstrated in Intellectual Ventures I LLC v. Capital One Bank (Fed. Cir. 2015), where the court determined "an abstract idea does not become nonabstract by limiting the invention to a particular field of use or technological environment, such as the Internet [or] a computer"). This/these limitation(s) do/does not impose any meaningful limits on practicing the abstract idea, and therefore do/does not integrate the abstract idea into a practical application (see MPEP 2106.05(h)).
The recited additional element(s) steps of involve requesting, by a user, to be added to the group of raffle sale participants and presenting a PAN as a payment method, receiving, by the merchant, the request and PAN related to the user, sending the PAN of the user to a financial institution responsible for payment processing, receiving the PAN by the financial institution, sending a list of selected winners to the merchant, receiving the list of winners by the merchant, and informing the selected winners and processing the payment for the product or service, represent mere data collection and transmission steps that occur before or after the core abstract idea of selecting winners of a raffle sale based on participant data. These activities are insignificant pre-solution and post-solution activity because they simply involve obtaining information to be used in the abstract idea and communicating the results of the abstract idea once the selection has been made. Data gathering steps such as collecting participant information and primary account numbers are considered insignificant pre-solution activity because they merely obtain information necessary for performing the abstract idea. Similarly, transmitting selection results or processing payments after winners are selected constitutes insignificant post-solution activity, as these steps merely communicate or implement the results of the abstract idea. Accordingly, the additional elements of independent claims the abstract idea into a practical application and constitute insignificant extra-solution activity and fail to integrate (Independent Claims 1, 10, and 12), additionally and/or alternatively simply append insignificant extra-solution activity to the judicial exception, (e.g., mere pre-solution activity, such as data gathering, in conjunction with an abstract idea). This/these limitation(s) do/does not impose any meaningful limits on practicing the abstract idea, and therefore do/does not integrate the abstract idea into a practical application. (See MPEP 2106.05(g)).
Dependent claims 2-9 fail to include any additional elements. In other words, each of the limitations/elements recited in respective dependent claims is/are further part of the abstract idea as identified by the Examiner for each respective dependent claim (i.e., they are part of the abstract idea recited in each respective claim).
The Examiner has therefore determined that the additional elements, or combination of additional elements, do not integrate the abstract idea into a practical application. Accordingly, the claim(s) is/are directed to an abstract idea (Step 2A – Prong two: NO).
Step 2B: In step 2B, the claims are analyzed to determine whether any additional element, or combination of additional elements, is/are sufficient to ensure that the claims amount to significantly more than the judicial exception. This analysis is also termed a search for an "inventive concept." An "inventive concept" is furnished by an element or combination of elements that is recited in the claim in addition to (beyond) the judicial exception, and is sufficient to ensure that the claim as a whole amounts to significantly more than the judicial exception itself. Alice Corp., 134 S. Ct. at 2355, 110 USPQ2d at 1981 (citing Mayo, 566 U.S. at 72-73, 101 USPQ2d at 1966).
As discussed above in “Step 2A – Prong 2”, the identified additional elements in independent Claims 1, 10, and 12, and dependent claims 2-9 are equivalent to adding the words “apply it” on a generic computer, and/or generally link the use of the judicial exception to a particular technological environment or field of use. Therefore, the claims as a whole do not amount to significantly more than the judicial exception itself.
The recited additional element(s) of outputting a plurality of tokens, presenting the communication record in a standardized form and displaying on a graphical user interface (Independent Claims 1, 10, and 12), additionally and/or alternatively simply append insignificant extra-solution activity to the judicial exception, (e.g., mere pre-solution activity, such as data gathering, in conjunction with an abstract idea), i.e. these steps merely perform the steps of requesting, by a user, to be added to the group of raffle sale participants and presenting a PAN as a payment method, receiving, by the merchant, the request and PAN related to the user, sending the PAN of the user to a financial institution responsible for payment processing, receiving the PAN by the financial institution, sending a list of selected winners to the merchant, receiving the list of winners by the merchant, and informing the selected winners and processing the payment for the product or service, represent mere data collection and transmission steps that occur before or after the core abstract idea of selecting winners of a raffle sale based on participant data, which is similar to “Receiving or transmitting data over a network, e.g., using the Internet to gather data”, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information), “Storing and retrieving information in memory”, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93; “Presenting offers to potential customers and gathering statistics generated based on the testing about how potential customers responded to the offers; the statistics are then used to calculate an optimized price”, OIP Technologies, 788 F.3d at 1363, 115 USPQ2d at 1092-93, Determining an estimated outcome and setting a price, OIP Techs., 788 F.3d at 1362-63, 115 USPQ2d at 1092-93, is a well-understood, routine, and conventional function when it is claimed in a merely generic manner (as it is here) (See MPEP 2106.05(d) (II)).
This conclusion is based on a factual determination. Applicant’s own disclosure at paragraph [0074-0082] acknowledges that “present disclosure it is appreciated that the Merchants do not have access to information regarding the payment history linked to a PAN, whilst Financial Institutions, like Mastercard©, possess the historical transaction information of Users at PAN level and therefore are able to create based on this historical transaction information, consumer profiles … informing the lucky Winners and the step of processing of the related payments will be executed using electronic means such as the servers of the Merchant.” This additional element therefore do not ensure the claim amounts to significantly more than the abstract idea.
Viewing the additional limitations in combination also shows that they fail to ensure the claims amount to significantly more than the abstract idea. When considered as an ordered combination, the additional components of the claims add nothing that is not already present when considered separately, and thus simply append the abstract idea with words equivalent to “apply it” on a generic computer and/or mere instructions to implement the abstract idea on a generic computer or/and append the abstract idea with insignificant extra solution activity associated with the implementation of the judicial exception, (e.g., mere data gathering, post-solution activity) and/or simply appending well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception.
The dependent claims 2-9 fail to include any additional elements. In other words, each of the limitations/elements recited in respective independent claims is/are further part of the abstract idea as identified by the Examiner for each respective dependent claim (i.e., they are part of the abstract idea recited in each respective claim).
Specifically, claims 2-9 likewise fail to integrate the abstract idea into a practical application. Claim 2 recites confirming receipt of the request to participate in the raffle. This step merely involves transmitting a confirmation message, which constitutes insignificant post-solution activity involving routine communication of information. Claim 3 recites defining random-based selection criteria in selecting winners. Claims 4, 6, 7, and 8 recite obtaining historic payment data linked to a PAN, retrieving consumer information from financial transaction databases, generating consumer profiles, and comparing the profiles with selection criteria. These limitations merely involve collecting, storing, and analyzing financial transaction data associated with payment accounts. The use of databases to retrieve transaction history and generate profiles represents routine data processing operations commonly performed by financial systems. Such steps do not improve computer functionality or any other technology and therefore do not add significantly more than the abstract idea. Claim 5 recites adding an anonym tag to a PAN to generate an anonymized raffle identifier linked to the PAN. Assigning identifiers to data records represents routine data organization and labeling, which is a conventional computer function that does not provide a technological improvement. Claim 9 recites informing raffle participants who were not selected as winners. This limitation merely involves communicating the results of the selection process. None of these limitations meaningfully limit the abstract idea or integrate it into a practical application. Accordingly, the additional limitations of the dependent claims do not amount to significantly more than the abstract idea and therefore fail to provide an inventive concept under Step 2B. Because these elements do not solve a specific technical problem or offer a technical improvement over existing systems, they are viewed as merely "applying" the abstract idea on a generic computer, thus failing to provide a practical application that would render the claims patent-eligible, and therefore do not add an inventive concept sufficient to transform the abstract idea into patent-eligible subject matter.
When viewed as an ordered combination, the additional elements of claims 2-8 merely instruct to implement the abstract idea using generic computer components to collect, store, represent, and display information. The claims do not recite any unconventional arrangement of elements, nor do they effect an improvement to computer functionality or another technical field and therefore fail to integrate the abstract concept into a practical application and it is recited at a high level of generality and does not integrate the judicial exception into a practical application.
The Examiner has therefore determined that no additional element, or combination of additional claims elements is/are sufficient to ensure the claim(s) amount to significantly more than the abstract idea identified above (Step 2B: NO).
Therefore, claims 1-10 and 12 are not eligible subject matter under 35 USC 101.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status:
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 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.
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 factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
Determining the scope and contents of the prior art.
Ascertaining the differences between the prior art and the claims at issue.
Resolving the level of ordinary skill in the pertinent art.
Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-10 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. 20180060847 (“Burch”) in view of U.S. Pub. 20180089648 (“Groarke”) in view of U.S. Pub. 20180096387 (“Vaidyanathan”).
As per claims 1, 10, and 12, Burch discloses, Computer implemented method for processing a Raffle Sale, comprising the steps of (Examiner interprets an electronic raffle system used to administer raffle ticket sales, process payments, and manage raffle data electronically) (“use of an electronic system to sell and issue the tickets and administer the necessary data to allow for the conduct of such a raffle or draw provides for the ability to sell the tickets in larger volume at a rapid pace”) (0005, 0003):
putting on sale, by a Merchant, of a product and/or a service via a Raffle Sale, wherein a number of selected Winners from a group of Raffle Sale participants receive the right to purchase said product and/or service (Examiner interprets a raffle system where participants purchase tickets and one or more winners are selected, thereby receiving the benefits associated with the raffle prize) (“Upon the receipt of a purchase transmission by the raffle server, payment for the tickets to be purchased will be processed by the payment gateway using the transmitted electronic payment details contained within the purchase transmission, and a ticket record will be created within the ticket database corresponding to each ticket sold for each raffle in question. Notification of the purchase and completion of the ticket sale can be provided back to the purchasor via their client device.”) (0015, 0007-0011, 0053),
defining, by the Merchant, criteria for the selection of Winners from a group of Raffle Sale participants (Examiner interprets that raffle records include rules, licenses, and conditions governing raffles and that the system extracts ticket records and selects winning tickets according to the raffle rules) (“the plurality of ticket records corresponding to the raffle will be extracted from the ticket database and at least one winning ticket can be selected there from and identified to the vendor and/or the purchasor of the ticket or tickets in question. The details of the at least one winning ticket will be transmitted to the vendor of the raffle, and the monetary proceeds of the raffle will be settled to the vendor. Each raffle record must contain details of an applicable license, to verify its legality and compliance with lottery sales) regulations, and the ticket sales transactions all take place directly between the raffle server and a purchasor through their client device, without in team any intermediate sales entities are hardware etc.” and “the server would extract the ticket records corresponding to the raffle in question from the ticket database and select at least one winning ticket therefrom, and transmit the details of the at least one winning ticket to the vendor along with settling the monetary proceeds of the raffle to the vendor and the at least one winner either directly or by facilitating the calculations for payment out of those amounts through third parties or other channels … facilitating the actual ticket sales, the raffles server of the present invention can also facilitate the assignment of raffle licenses to raffles in the system as raffle records were created or maintained within the raffle database. The ticketing server software component can assign a license to a raffle in the creation of a raffle record by contacting a license issuing server with the details of the raffle and the vendor, and receiving the details of an issued license for storage in the raffle record, or in other cases the ticketing server software component might store the details of a shared group license which was available to the operator of the raffle server for these purposes. Any type of server approach which entails either the manual or automated capture of the details of an applicable raffle license with respect to each raffle corresponding to a raffle record in the raffle database”) (0016 and 0028-0031),
requesting, by a User, to be added to the group of Raffle Sale participants and presenting, by said User, a PAN primary account number (PAN) as payment method (Examiner interprets a user purchasing raffle tickets through a client device by entering electronic payment details, which reasonably includes payment card numbers such as a Primary Account Number (PAN)) (“in respect of each ticket sale, allowing the purchasor having a purchase record, via the user interface of a client device, to authenticate themselves to the raffle server and subsequently receive and view via the user interface of the client device the details of any available raffles … purchasor can purchase at least one ticket in the at least one available raffle via the user interface of the client device by selecting at least one of the raffles in respect of which a ticket purchase is desired, selecting the purchase details for the tickets to be purchased and entering electronic payment details in respect of the ticket purchase. The selected and entered purchase details will be transmitted to the raffle server, including the raffle record identifier, purchasor record identifier and electronic payment details of each ticket sale to the raffle server, in a purchase transmission”) (0013-0014, 0054-0059),
receiving, by the Merchant, the request of the User to be added to the group of Raffle participants and the PAN related with the User (Examiner interprets the raffle server receiving purchase transmissions containing ticket purchase details and electronic payment information, which inherently includes payment account identifiers) (“allowing a purchasor who has a purchaser record in the purchasor database to use the user interface is the client device to authenticate themselves to the raffle server, received and reviewed by the user interface of the client devices details of any available raffles, the available raffles being raffles for which the defined time period remains open and for which the raffle qualification criteria of the purchasor satisfied the raffle of the ability criteria of the raffle, and then to purchase at least one ticket and at least one available raffles by the user interface of the client device by selecting at least one available raffle in respect of which at ticket purchases desired, selecting the purchase details the tickets to be purchased and entering electronic payment details in respect of the ticket purchase. It is specifically contemplated that purchasor could buy tickets in more than one available raffle at the same time, in one transaction which will result in the creation of multiple ticket records and the ticket database on the back end of the transaction is completed … particular purchasor would be displayed to the purchasor via the user interface of the client device, shown at 1A-3. The purchasor could then select the ticket or tickets they wish to purchase in one or more available raffles, and enter payment details for their ticket purchase, shown at 1A-4. The specific interface which could be used to display this information and transact the sale of tickets will be understood to those skilled in the art web interface design and any web interface capable of displaying and facilitating the sale transactions for the sale of tickets in one or more raffles at the same time if that list of available raffles contains more than one raffle”) (0054-0059),
applying, by the Financial Institution, the criteria for the selection of Winners from the group of Raffle Sale participants to select a number of Winners (Examiner interprets the raffle server extracting ticket records and selecting winning tickets when the raffle sales period closes) (“expiry of the defined time period for a raffle, the server would extract the ticket records corresponding to the raffle in question from the ticket database and select at least one winning ticket therefrom, and transmit the details of the at least one winning ticket to the vendor along with settling the monetary proceeds of the raffle to the vendor and the at least one winner either directly or by facilitating the calculations for payment out of those amounts through third parties or other channels. Each raffle record in the raffle database would contain details of the applicable license to that raffle, and the ticket sales transactions each take place directly between the server and the purchasor without any intermediate sales entities … raffle server is explicitly contemplated to be of great utility in the operation of a “service bureau”, where the raffle database contains raffle records corresponding to raffles operated by more than one vendor) (0028-0031),
sending, by the Financial Institution, a list of selected Winners to the Merchant (Examiner interprets transmitting the details of the winning ticket(s) to the vendor and facilitating settlement of raffle proceeds) (“Based on the raffle qualifying criteria contained within the purchasor record, or which is entered to create the purchasor record, the ticketing server software component could present to the purchasor via the user interface of the client device a list of available raffles in which they can purchase tickets at that particular time. The user could select one or more raffles, operated by one or more operators or vendors, via the interface of their device and transmit a sales request along with electronic payment details back to the server, where the purchase of the tickets could be electronically facilitated, and ticket records created in the ticket database in respect of each ticket sale in each raffle. Following the closure of a particular raffle sales window, the system can automatically choose one or more winning tickets from the ticket records in the ticket database corresponding to sales in respect of that raffle and the closing fulfillment or payout in the raffle, both to the vendor as well as to the winner or winners, could be completed or facilitated”) (0024),
receiving, by the Merchant, the list of selected Winners of the Raffle Sale (Examiner interprets the server transmitting winning ticket information to the raffle vendor) (“the server would extract the ticket records corresponding to the raffle in question from the ticket database and select at least one winning ticket therefrom, and transmit the details of the at least one winning ticket to the vendor along with settling the monetary proceeds of the raffle to the vendor and the at least one winner either directly or by facilitating the calculations for payment out of those amounts through third parties or other channels”) (0028),
and informing, by the Merchant, the selected Winners and processing the payment of the product and/or service for the selected Winners (Examiner interprets a raffle closing module that selects winning tickets and communicates results while also processing payment transactions via a payment gateway) (“a raffle closing module 75, which may or may not be a freestanding subroutine within the ticket server software component 7, but which would accomplish the other related system transactions and reporting etc. which might be required to close out a raffle when the raffle sales window closes i.e. extracting the relevant set of ticket records from the ticket database 6, selecting the winning tickets therefrom and communicating that information along with settlement of raffle proceeds to the vendor of the raffle … The server 2, either within the ticketing server software component 7 or as a freestanding software or software or hardware combination, would also include or access a payment gateway, through which ticket purchases could be processed. On transmission of the necessary information from the client device 10 of the purchasor to the server 2 resulting in the completion of the ticket sale and the creation of a ticket record 52, that transmission from the client device 10 would include either by way of instant data entry at the user interface of the client device 10, or by reference to archived payment details stored within the purchasor record 50 of the purchasor in question, credit card or other similar payment details which could be used to facilitate a payment transaction to pay for the raffle tickets being sold) (0150-0152).
Burch specifically doesn’t disclose, sending, by the Merchant, the PAN of the User as a participant to the Raffle Sale, to a Financial Institution, responsible for the payment processing of payments linked with the PAN, however Groarke discloses, sending, by the Merchant, the PAN of the User as a participant to the Raffle Sale (Examiner interprets the financial systems maintaining card profile data based on payment account history) (“The billing data includes a primary account number (PAN), an expiry date, and/or other information associated with account-on-file transactions. The billing data received from the issuers may include updated billing data that replaces expired billing data for a payment account. If a merchant enrolled in the ABU service wishes to verify billing data for account-on-file transactions, the merchant may, directly or indirectly through an acquirer, submit an update request to the ABCPU computing device. In certain embodiments, multiple update requests from one or more merchants may be collected by an acquirer and submitted to the ABCPU computing device as a batch file”) (0018), to a Financial Institution, responsible for the payment processing of payments linked with the PAN (“a merchant receives card profile data for a candidate payment account registered for a service provided by the merchant. The card profile data includes historical transaction data and spending behaviors for the candidate payment account. Based on the transaction data and the spending behaviors, the merchant determines that services similar to the service provided by merchant are generally cancelled after six months. The merchant may push a loyalty reward or other incentives to the cardholder of the candidate payment account after five months to attempt to keep the cardholder as a customer.”) (0027-0029).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the applicant’s invention for putting on sale, by a Merchant, of a product and/or a service via a Raffle Sale, wherein a number of selected Winners from a group of Raffle Sale participants receive the right to purchase said product and/or service, defining, by the Merchant, criteria for the selection of Winners from a group of Raffle Sale participants, requesting, by a User, to be added to the group of Raffle Sale participants and presenting, by said User, a PAN primary account number (PAN) as payment method, receiving, by the Merchant, the request of the User to be added to the group of Raffle participants and the PAN related with the User, applying, by the Financial Institution, the criteria for the selection of Winners from the group of Raffle Sale participants to select a number of Winners, sending, by the Financial Institution, a list of selected Winners to the Merchant, receiving, by the Merchant, the list of selected Winners of the Raffle Sale, and informing, by the Merchant, the selected Winners and processing the payment of the product and/or service for the selected Winners, as taught by Burch, sending, by the Merchant, the PAN of the User as a participant to the Raffle Sale, to a Financial Institution, responsible for the payment processing of payments linked with the PAN, as taught by Groarke for the purpose to employ anonymized identifiers for payment credentials to enhance security and privacy of PAN information.
Burch specifically doesn’t disclose, receiving, by the Financial Institution, the PAN of the User and adding the User to a group of Raffle Sale participants, however Vaidyanathan discloses, receiving, by the Financial Institution, the PAN of the User and adding the User to a group of Raffle Sale participants (Examiner interprets payment systems receiving payment information and processing transactions through payment servers) (“The payment initiating module 404 allows the one or more payees 112A-N to initiate the payment transaction against the product or the service purchased from the payee in the location. In one embodiment, the payment transaction is initiated by the one or more payees 112A-N in the one or more payee devices 108A-N. In another embodiment, the payment transaction is initiated by the one or more payees 112A-N in the one or more payee devices 108A-N using an e-commerce website. In yet another embodiment, the payment transaction is initiated by the one or more payees 112A-N in the one or more payee devices 108A-N using an online store. The payment information communicating module 406 communicates the payment information after initiating the payment transaction. The payment status obtaining module 408 receives the status after completion of the payment. In one embodiment, the status is stored in the payee device database 402. In one embodiment payee device 108A, further includes a payee server that directly (i) selects one or more market promotions, (ii) communicates the one or more payer targeted market promotions to the payment integration server 110 in real time.”) (0048).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the applicant’s invention for putting on sale, by a Merchant, of a product and/or a service via a Raffle Sale, wherein a number of selected Winners from a group of Raffle Sale participants receive the right to purchase said product and/or service, defining, by the Merchant, criteria for the selection of Winners from a group of Raffle Sale participants, requesting, by a User, to be added to the group of Raffle Sale participants and presenting, by said User, a PAN primary account number (PAN) as payment method, receiving, by the Merchant, the request of the User to be added to the group of Raffle participants and the PAN related with the User, applying, by the Financial Institution, the criteria for the selection of Winners from the group of Raffle Sale participants to select a number of Winners, sending, by the Financial Institution, a list of selected Winners to the Merchant, receiving, by the Merchant, the list of selected Winners of the Raffle Sale, and informing, by the Merchant, the selected Winners and processing the payment of the product and/or service for the selected Winners, as taught by Burch, receiving, by the Financial Institution, the PAN of the User and adding the User to a group of Raffle Sale participants, as taught by Vaidyanathan for the purpose to utilize the transaction history and consumer profiling to improve targeting based on consumer data.
As per claims 2, Burch discloses, wherein after the step of receiving, by the Merchant, of the request of the User to be added to the group of Raffle participants and the PAN related with the User the method further, comprises: confirming, by the Merchant, the receipt of the request to the User (Examiner interprets the system notifies the purchaser of purchase completion after ticket sales processing) (“the closure of a particular raffle sales window, the system can automatically choose one or more winning tickets from the ticket records in the ticket database corresponding to sales in respect of that raffle and the closing fulfillment or payout in the raffle, both to the vendor as well as to the winner or winners, could be completed or facilitated”) (0024, 0033).
As per claims 3, Burch discloses, wherein the step of defining, by the Merchant, criteria for the selection of Winners from a group of Raffle Sale participants comprises: defining random-based selection criteria for selecting Winners (Examiner interprets selecting winning tickets from the ticket database inherently represents a random raffle draw process) (“the server would extract the ticket records corresponding to the raffle in question from the ticket database and select at least one winning ticket therefrom, and transmit the details of the at least one winning ticket to the vendor along with settling the monetary proceeds of the raffle to the vendor and the at least one winner either directly or by facilitating the calculations for payment out of those amounts through third parties or other channels. Each raffle record in the raffle database would contain details of the applicable license to that raffle, and the ticket sales transactions each take place directly between the server and the purchasor without any intermediate sales entities”) (0028, 0024, 0033).
As per claims 4, Burch discloses, wherein the step of defining, by the Merchant, criteria for the selection of Winners from a group of Raffle Sale participants comprises: defining criteria for the selection of Winners, based on historic payment data, linked with a PAN (Examiner interprets that purchaser qualification information stored within purchaser records may include various account-related attributes associated with a purchaser's payment activity and transaction participation. Such stored information represents historical data associated with the purchaser account that can be used for eligibility or selection criteria. Therefore, Burch teaches defining selection criteria based on stored purchaser-related information associated with raffle participation) (“to offer for sale tickets in raffles or lotteries that were limited to be sold only to people of a particular age, people residing in a particular jurisdiction, or individuals having other pre-qualifications of the like, details of the qualification of the purchaser's in support of these criteria could be captured when the purchasor record was created and used for comparative purposes at the time of the querying or sale of the ticket. For example, by storing the age of the purchasor in the purchasor record corresponding to, the age of the purchasor can be used as a query or a filter against the raffle records in the raffle database at the time that a purchase query is made, so that only raffles which can be sold to people of that particular age would be shown as available raffles. It will be understood that a number of different types of raffle qualification criteria could be created, to meet virtually any type of a legislative or regulatory regime applicable to lotteries and raffles in a particular jurisdiction. Capturing any type of raffle qualification criteria of the purchasor which could be stored in the purchasor record in the purchasor database, or in a related site card data structure”) (0070, 0082).
As per claims 5, Burch discloses, wherein the step of Receiving, by the Financial Institution, the PAN of the User and adding the User to a group of Raffle Sale participants, further comprises: adding, by the Financial Institution, an anonym tag to the PAN to obtain an anonym RaffleID linked to the PAN (Examiner interprets that storing and referencing a purchaser through a system-generated identifier (e.g., purchaser identifier 53) functions as an internal identifier linked to payment credentials or purchaser records rather than directly exposing payment credentials. Such identifiers correspond to anonymized or abstracted identifiers linked to payment accounts. Therefore, Burch teaches associating purchaser accounts with internal identifiers representing participants within the raffle system) (“raffle server contains or is operatively connected to a purchasor database which is comprised of a plurality of purchasor records, each of which purchasor records corresponds to a retail purchasor of raffle tickets and includes identifying particulars of the purchasor as well as any raffle qualification criteria of the purchasor, being criteria used to determine the qualification of the purchasor to buy tickets in particular raffles. In addition to the purchasor database, the raffle server is also operatively connected to or hosts a raffle database comprising a plurality of raffle records. Each raffle record corresponds to a raffle offered for sale by a vendor and includes ticket price information as well as a defined time period within which tickets in the raffle can be sold, details of a license applicable to the raffle and any raffle availability criteria, being criteria which must be met by purchasors in order to purchase tickets in the raffle” and “purchasor identifier 53 as shown in the embodiment of FIG. 5, purchasor particulars 54 would also be stored in respect of the purchasor in question. This could for example be a username, password, name and address or other particulars of the purchasor that it was desired to capture either for the purpose of the technical operation of the system, or insofar as those persons or particulars 54 might be required for record-keeping purposes in the sale of raffle tickets and particular raffles. For example, in so far as lotteries and raffles are often regulated and required the capture of certain information related to the purchasor of tickets, address information or the like which might be required from the perspective of record-keeping could be captured from the purchasor and stored in the purchasor record 50 as one or more purchasor particulars 54”) (0011 and 0100).
As per claims 6, Burch specifically doesn’t disclose, using, by the Financial Institution, a Database comprising information relating to financial transactions and/or behaviour relating to the PAN to obtain consumer information related to the PAN, however Groarke discloses, using, by the Financial Institution, a Database comprising information relating to financial transactions and/or behaviour relating to the PAN to obtain consumer information related to the PAN (Examiner interprets that the prior art discloses databases storing card profile data including transaction history and spending behavior) (“, a merchant receives card profile data for a candidate payment account registered for a service provided by the merchant. The card profile data includes historical transaction data and spending behaviors for the candidate payment account. Based on the transaction data and the spending behaviors, the merchant determines that services similar to the service provided by merchant are generally cancelled after six months. The merchant may push a loyalty reward or other incentives to the cardholder of the candidate payment account after five months to attempt to keep the cardholder as a customer” and “The card profile data includes information associated with payment accounts and/or cardholders of the payment accounts. For example, card profile data may include, but is not limited to, historical transaction data, shopping behaviors, reported fraudulent activity, chargeback history, and/or other transaction-based profiles associated with a cardholder and a payment account of the cardholder. Although card profile database 114 is shown as single database, it is to be understood that database 114 may be a plurality of databases in communication with ABCPU computing device 108 over second network 122. Each database may profile a particular data element of the card profile data (e.g., shopping behaviors in one database and fraud history in another). In the example embodiment, the card profile data is generated and/or collected by payment processor 110”) (0027 and 0047).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the applicant’s invention for putting on sale, by a Merchant, of a product and/or a service via a Raffle Sale, wherein a number of selected Winners from a group of Raffle Sale participants receive the right to purchase said product and/or service, defining, by the Merchant, criteria for the selection of Winners from a group of Raffle Sale participants, requesting, by a User, to be added to the group of Raffle Sale participants and presenting, by said User, a PAN primary account number (PAN) as payment method, receiving, by the Merchant, the request of the User to be added to the group of Raffle participants and the PAN related with the User, applying, by the Financial Institution, the criteria for the selection of Winners from the group of Raffle Sale participants to select a number of Winners, sending, by the Financial Institution, a list of selected Winners to the Merchant, receiving, by the Merchant, the list of selected Winners of the Raffle Sale, and informing, by the Merchant, the selected Winners and processing the payment of the product and/or service for the selected Winners, as taught by Burch, using, by the Financial Institution, a Database comprising information relating to financial transactions and/or behaviour relating to the PAN to obtain consumer information related to the PAN, as taught by Groarke for the purpose to employ anonymized identifiers for payment credentials to enhance security and privacy of PAN information.
As per claims 7, Burch specifically doesn’t disclose, using, by the Financial Institution, a Database comprising information relating to financial transactions and/or behaviour relating to the PAN to obtain consumer information related to the PAN, however Groarke discloses, using, by the Financial Institution, the obtained consumer information to create a Consumer Profile linked to the PAN (Examiner interprets that the prior art further discloses creation of card profile databases linking transaction data with payment accounts) (“database system 610 is divided into a plurality of sections, including but not limited to, a billing data section 612, a card profile data section 614, and a merchant data section 616. Merchant data section 616 may include, for example, a list of registered merchants for the ABCPU service and/or the settings provided by issuers or cardholders to provide selective access to the update response. These sections are separated between databases 112, 114 (e.g., billing data section 112 is stored in ABU database 112). Databases 112, 114 are interconnected through ABCPU computing device 108 to update and retrieve the information as required”) (0075, 0047).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the applicant’s invention for putting on sale, by a Merchant, of a product and/or a service via a Raffle Sale, wherein a number of selected Winners from a group of Raffle Sale participants receive the right to purchase said product and/or service, defining, by the Merchant, criteria for the selection of Winners from a group of Raffle Sale participants, requesting, by a User, to be added to the group of Raffle Sale participants and presenting, by said User, a PAN primary account number (PAN) as payment method, receiving, by the Merchant, the request of the User to be added to the group of Raffle participants and the PAN related with the User, applying, by the Financial Institution, the criteria for the selection of Winners from the group of Raffle Sale participants to select a number of Winners, sending, by the Financial Institution, a list of selected Winners to the Merchant, receiving, by the Merchant, the list of selected Winners of the Raffle Sale, and informing, by the Merchant, the selected Winners and processing the payment of the product and/or service for the selected Winners, as taught by Burch, using, by the Financial Institution, the obtained consumer information to create a Consumer Profile linked to the PAN, as taught by Groarke for the purpose to employ anonymized identifiers for payment credentials to enhance security and privacy of PAN information.
As per claims 8, Burch specifically doesn’t disclose, comparing, by the Financial Institution, the obtained Consumer Profiles with the defined selection criteria based on historic payment data, linked with a PAN, however Groarke discloses, wherein the step of applying, by the Financial Institution, the criteria for the selection of Winners from the group of Raffle Sale participants to thereby select a number of Winners comprises: comparing, by the Financial Institution, the obtained Consumer Profiles with the defined selection criteria based on historic payment data, linked with a PAN (Examiner interprets that comparing stored payment account data with stored transaction-related profiles represents the use of consumer profiles associated with payment accounts to perform data comparisons or decision operations. Such comparisons may be used to determine eligibility, qualification, or selection criteria for payment-related services. Therefore, Groarke teaches comparing consumer profile information derived from transaction history with defined criteria associated with payment accounts) (“ABCPU computing device 108 compares the billing data from update request 204 (i.e., account identifier 206 and an expiry date) to billing data 202 of a corresponding record in ABU database 112. If the billing data of update request 204 does not match, billing data 202 within ABU database 112 is determined to be updated. Alternatively, ABCPU computing device 108 and/or ABU database 112 may maintain a record or log (not shown) that indicates when each record of billing data 202 was updated by issuer 102 and the last time update request 204 was sent by merchant 104. If billing data 202 was updated after the last update request from merchant 104, ABCPU computing device 108 identifies billing data 202 as updated.”) (0052, 0047, 0058).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the applicant’s invention for putting on sale, by a Merchant, of a product and/or a service via a Raffle Sale, wherein a number of selected Winners from a group of Raffle Sale participants receive the right to purchase said product and/or service, defining, by the Merchant, criteria for the selection of Winners from a group of Raffle Sale participants, requesting, by a User, to be added to the group of Raffle Sale participants and presenting, by said User, a PAN primary account number (PAN) as payment method, receiving, by the Merchant, the request of the User to be added to the group of Raffle participants and the PAN related with the User, applying, by the Financial Institution, the criteria for the selection of Winners from the group of Raffle Sale participants to select a number of Winners, sending, by the Financial Institution, a list of selected Winners to the Merchant, receiving, by the Merchant, the list of selected Winners of the Raffle Sale, and informing, by the Merchant, the selected Winners and processing the payment of the product and/or service for the selected Winners, as taught by Burch, comparing, by the Financial Institution, the obtained Consumer Profiles with the defined selection criteria based on historic payment data, linked with a PAN, as taught by Groarke for the purpose to employ anonymized identifiers for payment credentials to enhance security and privacy of PAN information.
As per claims 9, Burch discloses, informing, by the Merchant, all Raffle Sale participants who have not been selected as Winners (Examiner interprets that the notification mechanisms inherently include informing participants of raffle outcomes) (“Only purchasors who qualified to purchase tickets in a particular licensed lottery or raffle would be permitted the opportunity to do so, and once the time when no for the lottery or raffles completed, the proceeds would be settled from the system and winners selected”) (0051, 0111).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. US. Pub. 20150332553 (“O'Hagan”).
O'Hagan outlines a method for electronically facilitated lottery in which the purchasor of a lottery ticket can selectively direct the beneficiary proceeds portion of their ticket purchase price to at least one lottery beneficiary. A ticketing server hosting a ticket database, in communication with a ticket sales system, allows for the sales of lottery tickets with the selection of at least one lottery beneficiary from a plurality of possible lottery beneficiaries being made at the time of sale of the ticket. Following closure of ticket sales, at least one winning ticket can be chosen and the lottery administration system can calculate the allocation of the total sales proceeds of the lottery between the at least one winning ticket and the selected beneficiaries associated with each of the sold lottery tickets.
26. Any inquiry concerning this communication or earlier communications from the examiner should be directed to GAUTAM UBALE whose telephone number is (571)272-9861. The examiner can normally be reached Mon-Fri. 7:00 AM- 6:30 PM PST.
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, Marissa Thein can be reached at (571) 272-6764. 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.
/GAUTAM UBALE/
Primary Examiner, Art Unit 3689