DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Application
The following is a Final Office Action. In response to Examiner's communication on 06/18/2025, Applicant on 11/17/2025, and amended Claims 1, 7, 8, 15. Claims 1-20 are now pending in this application and have been rejected below.
Response to Amendment
Applicants’ amendments are insufficient to overcome the 35 USC 101 rejections set forth in the previous action.
Applicants’ amendments render moot the 35 USC 103 rejections set forth in the previous action in view of new and updated grounds for rejection necessitated by Applicants’ amendments. Therefore, these rejections are withdrawn in view of the new grounds for rejection necessitated by Applicants’ amendments, as set forth below.
Applicants’ amendments are insufficient to overcome the 35 USC 103 rejections set forth in the previous action. Therefore, these rejections have been updated to address the amendments and are maintained below.
Response to Arguments – 35 USC § 101
Applicant's arguments with respect to the 35 USC 101 rejections have been fully considered but they are not persuasive.
Applicant argues that even if the claims involve an abstract idea, which Applicant disputes, the claims are integrated into a practical application and additionally represent significantly more per Step 2B of the analysis because while some steps may arguably recite an abstract idea, in view of the ordered combination of the steps of using GUI elements in an inventive manner, the claim as a whole is directed to an improvement to the particular field of the application. Examiner respectfully disagrees.
Pursuant to MPEP 2106, in order to determine whether a claim is directed to an abstract idea, under Step 2A, we first (1) determine whether the claims recite limitations, individually or in combination, that fall within the enumerated subject matter groupings of abstract ideas (mathematical concepts, certain methods of organizing human activity, or mental processes), and (2) determine whether any additional elements beyond the recited abstract idea, individually and as an ordered combination, integrate the judicial exception into a practical application. MPEP 2106.04.
Next, if a claim (1) recites an abstract idea and (2) does not integrate that exception into a practical application, in order to determine whether the claim recites an “inventive concept,” under Step 2B, we then determine whether any of the additional elements beyond the recited abstract idea, individually and in combination, are significantly more than the abstract idea itself. MPEP 2106.05.
That is, only after determining whether the claims recite limitations that, individually or in combination, that fall within one of the enumerated subject matter groups of abstract ideas in the first prong of Step 2B, under the second prong of Step 2A, we determine whether any additional elements beyond the recited abstract idea, individually and as an ordered combination, integrate the judicial exception into a practical application. However, the steps referred to by Applicant are not additional elements beyond the recited abstract idea, but rather, for the reason detailed in the following paragraphs, the limitations referred to by Applicant are part of and directed to the recited abstract idea because they are recitations of mental
processes that can be practically performed mentally and merely use generic computer components as a tool (the GUI elements as outlined in Claim 1) to implement the mental processes.
As set forth in the MPEP, mere automation of a manual or mental process or a business method being applied on a general purpose computer is not sufficient to show an improvement in computers or other technology, and the claim must include more than mere instructions to perform the method on a generic component or machinery to qualify as an improvement to an existing technology. MPEP 2106.05(a). Merely requiring that the claims use generic computer components, such as the front-ends systems with graphical user interfaces, to implement the recited abstract idea does not make the claims directed to an improvement in technology or otherwise transform the abstract idea into a patent eligible invention.
The steps referred to by Applicant do not recite a significant improvement in technology, but rather, the steps referred to by Applicant are recitation of mental processes that can be practically performed mentally and merely use a generic computer components as a tool (i.e., a “front-end system configured to provide a graphical user interface” in Claim 1) to implement the mental process. In fact, aside from the generic component used as a tool to implement the steps, the steps referred to by Applicant are not additional elements beyond the recited abstract idea, but, as noted above, they are recitations of mental processes that recite an abstract idea.
Viewing the limitations in combination per the pen and paper test recited in MPEP 2106.04(a)(2)(iii), a human can mentally organize an event and mentally receive salient information with respect to a set of clubs, mentally perform a judgement in response the collection of said data, mentally store data regarding club requirements, exhibition results, and mentally create a report with aid of pen and paper, and perform a mental judgement to update salient information in response to purchases by aid of pen and paper.
In combination, these steps do not reflect an improvement in computer technology, but rather a mental process of organizing a competition. Additionally, as what is claimed falls under the purview of facilitating of sales in said competition, and the maintenance of information pertaining to sign-in and sign-out, the claims additionally recite a Certain Method of Organizing Human Activity, namely a Fundamental Economic Practice and Managing Personal Behavior or Relationships or Interactions Between People.
As detailed below with respect to the second prong of Step 2A, the recited abstract idea is not integrated into a practical Application because the additional elements beyond the recited abstract idea merely use generic computer components as a tool to apply the recited abstract idea.
As set forth in the MPEP, mere automation of a manual or mental process or a business method being applied on a general purpose computer is not sufficient to show an improvement in computers or other technology, and the claim must include more than mere instructions to perform the method on a generic component or machinery to qualify as an improvement to an existing technology. MPEP 2106.05(a). Merely requiring that the claims use generic computer components, such as the generically recited machine learning model, to implement the recited abstract idea does not make the claims directed to an improvement in technology or otherwise transform the abstract idea into a patent eligible invention. Further, with respect to the particular configuration of a plurality of front ends recited at a high level of generality in Claim 1, this configuration does not amount to an improvement in computers or other technology,
Like in Electric Power Group, the claims are not focused on a specific improvement in computers, but on certain independently abstract ideas that simply use computers as tools. Electric Power Group, LLC v. Alstom S.A,, et al., No. 2015-1778, slip op. at 8 (Fed. Cir. Aug. 1, 2016); MPEP 2106.05(a).
Similarly, the limitations referred to by Applicant in Claims 3-15 are merely recitations of mental processes that can be performed by a human mentally receiving data and performing a mental evaluation and judgement using the observed information, recording salient information by aid of pen and paper.
Response to Arguments –35 USC § 103
Applicant' s arguments with respect to the rejection of Claims 1-20 under 35 USC 103 have been considered but are moot in light of new grounds of rejections necessitated by applicant’s amendments.
Applicant argues that correspondence is not shown and a valid rationale has not been presented to combine the references as suggested. Examiner respectfully disagrees.
Noting MPEP 2141.01(a), Analogous and Nonanalogous art, “A reference is analogous art to the claimed invention if: (1) the reference is from the same field of endeavor as the claimed invention (even if it addresses a different problem); or (2) the reference is reasonably pertinent to the problem faced by the inventor (even if it is not in the same field of endeavor as the claimed invention)”. That the fields be disparate need not
preclude the combination of the references as cited, as we are able to use
the second standard of “reasonable pertinence”. Conlan discloses a system for managing a horse exhibition. Cella discloses a system meant to facilitate licensing transactions. Hwan discloses a system meant to administer the purchasing and selling of horses. Extending the system for facilitating horse transactions as recorded in Hwan and the system for managing ownership information of Cobb to the system for horse exhibition management as mentioned in Conlan is applicable as Conlan already provides support for horse buyers and sellers – see [0042] of Conlan; the only thing missing is the means for actually facilitating the transactions. Extending the control of licensing allowed for by Cella is applicable to Conlan because we already have means for associations sponsoring different events – see [0051] of Conlan. Adding means to regulate the provision and conditions of such sponsorships, derived from Cella, would be applicable to Conlan’s event management architecture. In both the case of Hwan and Cella, we have reasonable pertinence to the central problems addressed by Conlan – namely, that of organizing an animal exhibition event with support for the sale of involved animals.
As for the motivation to combine such references, the claim is plainly directed to the predictable result of combining known items in the prior art, with the expected benefit that adopting the transaction infrastructures of Hwan and Cobb would enable users to streamline the purchasing and sale of horses, and that adopting the licensing control of Cella would give sponsoring associations the means to intelligently specify their needs and wants as it pertains to granting sanctions.
The rejections under 35 USC 103 have been updated to address the amendments 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 an abstract idea without significantly more.
101 Analysis – Step 1
The claims are directed to an apparatus. Therefore, the claims are directed to at least one of the four statutory categories.
101 Analysis – Step 2A
Regarding Prong 1 of the Step 2A analysis in the MPEP, the claims are to be analyzed to determine whether they recite subject matter that is directed to a judicial expectation, namely a law of nature, a natural phenomenon, or one of the follow groups of abstract ideas: a) mathematical concepts, b) certain methods of organizing human activity, and/or c) mental processes.
Independent Claim 1 includes limitations that recite an abstract idea and will henceforth be used as a representative claim for the 101 rejection until otherwise noted. Claim 1 recites:
A system for management of events, comprising: a back-end system; the back-end system having a database; the back-end system having a data processing system; a first front-end system communicatively connected to the back-end system; the first front-end system configured to provide a graphical user interface for an event host to create and configure an event and select a set of clubs the event host would like to sanction the event; wherein in response to the set of clubs being selected via the graphical user interface provided by the first front-end system, the data processing system submits applications for purchase of sanctions from the set of clubs for the event; wherein the data processing system is configured to track approval status of the applications for purchase of sanctions in the database; wherein the data processing system is configured to store respective sets of club requirements for approved sanctions of the set of sanction sanctions in the database; wherein the data processing system is configured to maintain configuration information for the event in the database; a second front-end system communicatively connected to the back-end system; the second front-end system configured to provide a graphical user interface for exhibitors to register for the event; wherein the data processing system is configured to maintain registration information for the exhibitors for the event in the database; wherein upon determining finalized results of the event for the exhibitors, the data processing system is configured to generate a customized report of the finalized results of the event for each of the approved sanctions according to the respective set of club requirements for the approved sanction; wherein the second front end system is configured to provide a graphical user interface that displays a respective check-in /check-out sheet for the exhibitors indicating information for animals the exhibitor registered to bring to the event; wherein the second front-end system is configured to permit a first one of the exhibitors to initiate a transaction for sale of at least one animal they registered to bring to the event to a second one of the exhibitors for a specified amount; wherein in response to the transaction being initiated, the data processing system is configured to electronically transfer payment for the specified amount from the second one of the exhibitors to the first one of the exhibitors; wherein in response to completing the transfer payment, the graphical user interface of the second front end system is configured to update the respective check-in /check-out sheets for the first one of the exhibitors and the second one of the exhibitors to remove the at least one animal from the check-in/check-out of the first one of the exhibitors and add the at least one animal to the check-in/check-out of the second one of the exhibitors.
The examiner submits that the foregoing bolded limitation(s) constitute an abstract idea because under its broadest reasonable interpretation, the claim covers a mental process and certain method for managing human behavior. “Create and configure an event and select a set of clubs”, “submits applications for purchase of sanctions, “track approval status of the applications”, “store respective sets of club requirements”, “maintain configuration information”, “register for the event”, “maintain configuration information for the exhibitors”, “upon determining finalizes results of the event…generate a customized report”, “generate a respective check-in/check-out sheet for each of the exhibitors”, “permit a first one of the exhibitors to initiate a transaction for sale”, “in response to the transaction being initiated…update the respective check-in/checkout sheets” are abstract ideas - namely, these are mental processes that could be performed by a human with a pen and paper, per the MPEP, merely adapting them into the context of a technological environment with computing parts does not preclude them from being abstract. Further, the objective of these tasks is to facilitate aspects of competition and tournament management, a human endeavor. Accordingly, the claim recites at least one abstract idea.
101 Analysis – Step 2A, Prong II
Regarding Prong II of the Step 2A analysis in the MPEP, the claims are to be analyzed to determine whether the claim, as a whole, integrates the abstract into practical application. As noted in the MPEP, it must be determined whether any additional elements in the claim beyond the judicial exception integrate the exception into a practical application in a manner that imposes a meaningful limit on the judicial exception. The courts have indicated that additional elements, such as merely using a computer to implement an abstract idea, adding insignificant extra solution activity, or generally linking use of a judicial exception to a particular technological environment or field of use do not integrate a judicial exception into a “practical application.
In the present case, the additional limitations beyond the above-noted abstract idea are as follows (where the underlined portions are the “additional limitations” while the bolded portions continue to represent the “abstract idea”):
A system for management of events, comprising: a back-end system; the back-end system having a database; the back-end system having a data processing system; a first front-end system communicatively connected to the back-end system; the first front-end system configured to provide a graphical user interface for an event host to create and configure an event and select a set of clubs the event host would like to sanction the event; wherein in response to the set of clubs being selected via the graphical user interface provided by the first front-end system, the data processing system submits applications for purchase of sanctions from the set of clubs for the event; wherein the data processing system is configured to track approval status of the applications for purchase of sanctions in the database; wherein the data processing system is configured to store respective sets of club requirements for approved sanctions of the set of sanction sanctions in the database; wherein the data processing system is configured to maintain configuration information for the event in the database; a second front-end system communicatively connected to the back-end system; the second front-end system configured to provide a graphical user interface for exhibitors to register for the event; wherein the data processing system is configured to maintain registration information for the exhibitors for the event in the database; wherein upon determining finalized results of the event for the exhibitors, the data processing system is configured to generate a customized report of the finalized results of the event for each of the approved sanctions according to the respective set of club requirements for the approved sanction; wherein the second front end system is configured to provide a graphical user interface that displays a respective check-in /check-out sheet for the exhibitors indicating information for animals the exhibitor registered to bring to the event; wherein the second front-end system is configured to permit a first one of the exhibitors to initiate a transaction for sale of at least one animal they registered to bring to the event to a second one of the exhibitors for a specified amount; wherein in response to the transaction being initiated, the data processing system is configured to electronically transfer payment for the specified amount from the second one of the exhibitors to the first one of the exhibitors; wherein in response to completing the transfer payment, the graphical user interface of the second front end system is configured to update the respective check-in /check-out sheets for the first one of the exhibitors and the second one of the exhibitors to remove the at least one animal from the check-in/check-out of the first one of the exhibitors and add the at least one animal to the check-in/check-out of the second one of the exhibitors.
For the following reason(s), the examiner submits that the above identified additional limitations do not integrate the above-noted abstract idea into a practical application.
The additional elements include a “data processing system”, “back-end system”, and three distinct uses of a “front-end system”. When considered in view of the claim as a whole, the additional elements do not integrate the abstract idea into a practical application because the additional elements are generic computing components that are merely used as a tool to perform the recited abstract idea and/or do no more than generally link the use of the recited abstract idea to a particular technological environment or field of use under Step 2A Prong Two.
Thus, taken alone, the additional elements do not integrate the abstract idea into a practical application. Further, looking at the additional limitation(s) as an ordered combination or as a whole, the limitation(s) add nothing that is not already present when looking at the elements taken individually. For instance, there is no indication that the additional elements, when considered as a whole, reflect an improvement in the functioning of a computer or an improvement to another technology or technical field, apply or use the above-noted judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, implement/use the above-noted judicial exception with a particular machine or manufacture that is integral to the claim, effect a transformation or reduction of a particular article to a different state or thing, or apply or use the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is not more than a drafting effort designed to monopolize the exception (MPEP § 2106.05). Accordingly, the additional limitation(s) do/does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing abstract idea.
101 Analysis – Step 2B
Regarding Step 2B of the MPEP, representative independent claim 1 does not include additional elements (considered both individually and as an ordered combination) that are sufficient to amount to significantly more than the judicial exception for the same reasons to those discussed above with respect to determining that the claim does not integrate the abstract idea into a practical application. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements amount to well-understood and routine activities that are conventional in the art.
Claims 2-5 include limitations which merely further limit the abstract ideas of Claim 1, and are therefore ineligible.
Claims 6-14 include limitations which merely further limit the extra-solution activity of Claim 1 and are therefore ineligible. Claims 18 and 19 are rejected as presenting substantially similar limitations.
Claims 15 and 20 contains substantially the same limitations as Claim 1 and are therefore ineligible for the same reasons. Claim 16-17 are rejected as merely limiting the extra-solution activity of Claim 15.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-14 are rejected under 35 U.S.C. 103 as being unpatentable over Conlan(US 20210012293 A1) in view of Cella(US 20210342836 A1) in further view of Hwan(KR20180046979A) in further view of Cobb(US 6582231 B1).
Claim 1
As to Claim 1,
Conlan teaches:
A system for management of events, comprising: a back-end system; the back-end system having a database; the back-end system having a data processing system;
In [0019], “FIG. 1 is a diagram 100 of an example of a system for event management. The diagram 100 includes a computer-readable medium (CRM) 102, a virtual venue datastore 104 coupled to the CRM 102, a venue mapping engine 106 coupled to the CRM 102, a fixture placement engine 108 coupled to the CRM 102, a dynamic location overlay engine 110 coupled to the CRM 102, a resource integration engine 112 coupled to the CRM 102, a resource tracking engine 114 coupled to the CRM 102, an environmental conditions estimation engine 116 coupled to the CRM 102, and an agent interface engine 118 coupled to the CRM 102.”
a first front-end system communicatively connected to the back-end system; the first front-end system configured to provide a graphical user interface for an event host to create and configure an event
In [0076], "In step 1602, a system (e.g., the system for event management depicted in FIG. 1) obtains rider locations for a plurality of horse riders of a horse show event". This is explicitly disclosed to interface with a graphical user interface In [0083], " In step 1610, the system provides an interface (e.g., graphical user interface) through which the first route and the second route are accessible (e.g., viewable, editable, and/or otherwise interactable). For example, the interface can include a first graphical layer overlaid over a second graphical layer. The first layer can be a dynamic layer and the second graphical layer can be a static map".Conlan does not teach:
and select a set of clubs the event host would like to sanction the event; wherein in response to the set of clubs being selected via the graphical user interface provided by the first front-end system, the data processing system submits applications for purchase of sanctions from the set of clubs for the event; wherein the data processing system is configured to track approval status of the applications for purchase of sanctions in the database; wherein the data processing system is configured to store respective sets of club requirements for approved sanctions of the set of sanction sanctions in the database;
However, Cella teaches:
and select a set of clubs the event host would like to sanction the event; wherein in response to the set of clubs being selected via the graphical user interface provided by the first front-end system, the data processing system submits applications for purchase of sanctions from the set of clubs for the event; wherein the data processing system is configured to track approval status of the applications for purchase of sanctions in the database; wherein the data processing system is configured to store respective sets of club requirements for approved sanctions of the set of sanction sanctions in the database;
In [0512], "In embodiments, the compliance system 13800 may provide a graphical user interface that allows users to create smart contracts governing personality rights licenses...In embodiments, the graphical user interface allows a user to define certain terms (e.g., the type or types of obligations placed on the licensor, an amount of funds to paid, a date by which the obligations of the licensor must be completed by, a location at which the obligation is completed, and/or other suitable terms). Upon a user providing input for parameterizing a smart contract template, the compliance system 13800 may generate a smart contract by parameterizing one or more variables in the smart contract with the provided input. Upon parameterizing an instance of a smart contract, the compliance system 13800 may deploy the smart contract. In some embodiments, the compliance system 13800 may deploy the smart contract by broadcasting the parameterized smart contract to the participant nodes, which in turn may update each respective instance of the distributed ledger with the new smart contract. In some embodiments, an institution of the licensor must approve the parameterized smart contract before the parameterized smart contract may be deployed to the distributed ledger. In [0513], " In this way, the licensor can prove that he or she performed the tasks required by the licensing deal. In some embodiments, the application may interact with a wearable device or may capture other digital exhaust, such as social media posts of the user (e.g., licensor) to collect evidence that supports or disproves a licensor's claim that he or she performed the obligations under the transaction agreement. In embodiments, the corroborating evidence collected by the application may be recorded by the application and stored on the distributed ledger as a licensor datastore 13856C". Note that given the recordation of the fulfillment of the contract occurs on the blockchain, we understand its approval status to be discernible from such; the same applies with the terms of the contract.
Conlan teaches:
wherein the data processing system is configured to maintain configuration information for the event in the database
In [0031], "The virtual venue datastore 104 is intended to represent a datastore of static and dynamic objects within a venue, which can include places, people, animals, and things that can be tracked in some manner (e.g., via manual methods, such as checklists, or via sensors located around a venue, including cameras that can use facial recognition to determine a location of a person, or radios that can detect RFID or other electromagnetic signals of devices, such as RFID tags affixed to an object or a wireless signal from a smartphone) or for which a location and time are otherwise provided. Static objects can include buildings, ski resorts, outdoor arenas, bodies of water, competition rings, tracks (including waypoints along a track), show grounds, tables, booths, entrances, exits, and other places or fixtures". In [0046], "Depending upon implementation-, configuration-, or preference-specific factors, dynamic venue maps can include, historic venue maps, a current venue map, and future venue maps. If an event is ongoing, one of the dynamic venue maps will be a current venue map and the others can be historic venue maps (if an event is over) or future venue maps (if an event has not yet begun)".
a second front-end system communicatively connected to the back-end system; the second front-end system configured to provide a graphical user interface for exhibitors to register for the event; wherein the data processing system is configured to maintain registration information for the exhibitors for the event in the database;
In [0050], "Referring once again to the example of FIG. 2, the participant registration engine 206 is intended to represent an engine that gathers information about participants and associated animals or devices, if applicable... Initial registration information can be shared with a venue, used to autofill future registrations, used to stop cross-entries, used to prevent registration for events for which a participant is ineligible, or the like, if applicable. In a horse show context, such information can include rider name (though a restriction on showing the last name of a minor may be enforced, assuming names are shared), rider association number(s), address, phone number, email, date of birth/age (note: show age changes December 1), and horse info (e.g., name, age, height, association number)". In [0072], "FIG. 13 is a screenshot 1300 of an example of an event list interface. As shown, the event list interface can display different events, and users can register to event(s), and/or add new event(s)".
Cella teaches:
wherein upon determining finalized results of the event for the exhibitors, the data processing system is configured to generate a customized report of the finalized results of the event for each of the approved sanctions according to the respective set of club requirements for the approved sanction
As outlined above, Cella gives us significant leeway as it pertains to the terms of the smart contract. In [0515], "In embodiments, the compliance system 13800 is configured to perform analytics and provide reports to a regulatory body and/or other entities (e.g., the other organizations)". An alternate feature of the invention discloses in [0450], " May generate a set of data record that define the facility or a set of facilities under common ownership or operation by a host. The data record may have any suitable schema...May generate content, such as a document, message, alert, report, webpage and/or application page based on the contents of the data record".
Conlan teaches:
wherein the second front end system is configured to provide a graphical user interface that displays a respective check-in /check-out sheet for the exhibitors indicating information for animals the exhibitor registered to bring to the event;
In [0050], "Referring once again to the example of FIG. 2, the participant registration engine 206 is intended to represent an engine that gathers information about participants and associated animals or devices, if applicable. In a specific implementation, registration can include entering multiple events (e.g., classes at a horse show in which a rider will compete). We consider the check-in/checkout sheet to be the information that the engine associates with a registered horse, which would encapsulate attendance at an event among various other information. Such information is graphically displayed in Fig. 5, see [0055], “FIG. 5 provides an example of event attendance management for a horse show context. FIG. 5 is a screenshot 500 of an example of an event participant status listing and management interface. Riders (competitors) are listed “in line” waiting to compete with a next in line to compete is highlighted and ready to be dragged “on course.” After a competitor is done, the competitor can be dragged to “done.” In an alternative, an event coordinator could automate the status update using location tracking. For example, a competitor with an RFID tag that is detected at the entrance to a course could cause the system to update status to “on course” automatically, making it unnecessary to drag-and-drop or perform some other manual interaction to accomplish the status change”.
Conlan and Cella do not teach:
wherein the second front-end system is configured to permit a first one of the exhibitors to initiate a transaction for sale of at least one animal they registered to bring to the event to a second one of the exhibitors for a specified amount;
However, Hwan teaches:
wherein the second front-end system is configured to permit a first one of the exhibitors to initiate a transaction for sale of at least one animal they registered to bring to the event to a second one of the exhibitors for a specified amount;
In [0010], " a terminal used by a horse seller who wishes to sell a horse, the horse seller terminal registering a horse specification sheet containing information about the horse and a horse riding video taken while the rider is riding the horse, in a horse transaction mediation server". In [0012], " a horse transaction payment unit that performs horse transaction payment processing by receiving the final horse purchase price or horse winning bid price from the horse buyer".
wherein in response to the transaction being initiated, the data processing system is configured to electronically transfer payment for the specified amount from the second one of the exhibitors to the first one of the exhibitors
In [0012], "a horse transaction payment unit that performs horse transaction payment processing by receiving the final horse purchase price or horse winning bid price from the horse buyer and depositing it into the horse seller's financial account".
Conlan does not teach:
wherein in response to completing the transfer payment, the graphical user interface of the second front end system is configured to update the respective check-in /check-out sheets for the first one of the exhibitors and the second one of the exhibitors to remove the at least one animal from the check-in/check-out of the first one of the exhibitors and add the at least one animal to the check-in/check-out of the second one of the exhibitors.
However, Cobb teaches:
wherein in response to completing the transfer payment, the graphical user interface of the second front end system is configured to update the respective check-in /check-out sheets for the first one of the exhibitors and the second one of the exhibitors to remove the at least one animal from the check-in/check-out of the first one of the exhibitors and add the at least one animal to the check-in/check-out of the second one of the exhibitors.
Understanding the relational database information to analogize to check-in and check-out sheets in Col 11, Lines 48-63, “In completing the ownership transfer recordation application 70 the parties fill in the seller's name and phone number and the date of sale, the new owner's name address and phone number and both parties sign the document in the spaces provided. The certificate 51 provides instructions instructing the seller or purchaser to provide or record a microchip number for the animal if not done previously. Upon receipt of the certificate 51 with the completed ownership transfer recordation application 70, the registry changes records the new information concerning the identity of the new owner of the animal in the relational database and enters a microchip number if provided and not previously entered in the relational database. The registry then prints a new certificate of registration 51 providing the identifying information for the new owner and sends the new certificate of registration 51 to the listed owner”.
Conlan discloses a system for managing a horse exhibition. Cella discloses a system meant to facilitate licensing transactions. Hwan discloses a system meant to administer the purchasing and selling of horses. Cobb discloses a system for facilitating conveyances of ownership to people participating in animal transactions. Extending the system for facilitating horse transactions as recorded in Hwan and the system for managing ownership information of Cobb to the system for horse exhibition management as mentioned in Conlan is applicable as Conlan already provides support for horse buyers and sellers – see [0042] of Conlan; the only thing missing is the means for actually facilitating the transactions. Extending the control of licensing allowed for by Cella is applicable to Conlan because we already have means for associations sponsoring different events – see [0051] of Conlan. Adding means to regulate the provision and conditions of such sponsorships, derived from Cella, would be applicable to Conlan’s event management architecture.
It would have been obvious to one having ordinary skill in the art at the effective filling date of the invention to combine the horse transaction management as taught in Hwan and the licensing control of Cella and apply that to the event management software as taught in Conlan . Motivation to do so comes from the fact that the claim is plainly directed to the predictable result of combining known items in the prior art, with the expected benefit that adopting the transaction infrastructures of Hwan and Cobb would enable users to streamline the purchasing and sale of horses, and that adopting the licensing control of Cella would give sponsoring associations the means to intelligently specify their needs and wants as it pertains to granting sanctions.
Claim 2
As to Claim 2, Conlan combined with Cella, Hwan and Cobb teaches all the limitations of Claim 1 as discussed above.
Cella teaches:
The system of claim 1, wherein the data processing system is configured to communicate the customized report to one of the set of clubs from which the sanction was purchased.
As outlined above, Cella gives us significant leeway as it pertains to the terms of the smart contract. In [0515], "In embodiments, the compliance system 13800 is configured to perform analytics and provide reports to a regulatory body and/or other entities (e.g., the other organizations)".
It would have been obvious to one having ordinary skill in the art at the effective filling date of the invention to integrate the licensing control as taught in Cella and apply that to event management system as taught in Conlan. Motivation to do so comes from the same rationale as outlined above with respect to Claim 1.
Claim 3
As to Claim 10, Conlan combined with Cella, Hwan and Cobb teaches all the limitations of Claim 1 as discussed above.
Conlan teaches:
The system of claim 1, wherein the respective set of club requirements for at least one of the approved sanctions requires payment of a fee per exhibitor
In [0051], "Associations (e.g., USEF, PCHA, NORCAL, OHJA) are tracked because they can sponsor multiple divisions and riders must be members of an association to capture points for sponsored division and class; association membership impacts eligibility to participate in classes". In [0068], "The scratch engine 1202 is intended to represent an engine that enables a show officer or agent thereof to cancel a competition class. In operation, a competitor pays for a competition class but may be unable to participate in the class, so they need to cancel (and therefore are not responsible for paying for the class)".
Conlan does not teach:
to the club from which the approved sanction was purchased; and wherein after closing of registration, the back-end system is configured to automatically calculate the total payment for the fee per exhibitor from data stored in the database; wherein the back-end system is configured to automatically submit the calculated total payment to the club from which the approved sanction was purchased.
However, Cella teaches:
to the club from which the approved sanction was purchased; and wherein after closing of registration, the back-end system is configured to automatically calculate the total payment for the fee per exhibitor from data stored in the database; wherein the back-end system is configured to automatically submit the calculated total payment to the club from which the approved sanction was purchased.
In [00902], "Upon execution of the smart contract 16840, the knowledge distribution system 16802 may automatically transfer access and licensing rights to the intellectual property to the knowledge recipient 16818 (e.g., knowledge recipient device 16894 of knowledge recipient 16818) according to terms and/or operations set forth in the smart contract 16840...In embodiments, the smart contract 16840 may contain one or more operations to be performed with respect to the distributed ledger 16808 to facilitate an execution defined by the smart contract 16840. In some embodiments, the smart contract 16840 may be configured to automatically allocate royalties in transfers between one or more knowledge providers 16806 and knowledge recipients 16818 (e.g., using knowledge provider devices 16890 and knowledge recipient devices 16894) involving transfer of access to, ownership of, and/or licensing rights to intellectual property. For example, if the owner of the digital knowledge pays licensing fees to a third-party patent owner of one or more aspects of the digital knowledge (e.g., the inventor of a particular product design), the smart contract may allocate a set percentage or amount of the transaction price of the digital knowledge 16804 to the licensor". Conceptualizing the clubs(associations) as licensors of intellectual property, and the event hosts as licensees that pay for a sanction, and the exhibitors as knowledge recipients, this anticipates the idea of automatic payments to the licensors from the payments of exhibitors. In this case, the set amount allocated to the licensor would exactly be the prescribed fee they set as a condition.
It would have been obvious to one having ordinary skill in the art at the effective filling date of the invention to integrate the licensing control as taught in Cella and apply that to event management system as taught in Conlan. Motivation to do so comes from the same rationale as outlined above with respect to Claim 1.
Claim 4
As to Claim 4, Conlan combined with Cella, Hwan and Cobb teaches all the limitations of Claim 1 as discussed above.
Cella also teaches:
The system of claim 1, wherein the respective set of club requirements for at least one of the approved sanctions requires the event to include a club-specific award.
As outlined above, Cella gives us significant leeway as it pertains to the terms of the smart contract. Integration of a reward in the terms of the smart contract is outlined in [0326], "Thus an allocation of rewards may be provided as a consideration within the context of a loan or agreement. Systems may be utilized to allocate rewards. The allocation of rewards in various forms may be included where discussing a particular behavior, or encouragement of a particular behavior, without limitation. An allocation of a reward may include an actual dispensation of the award, and/or a recordation of the reward. The allocation of rewards may be performed by a smart contract circuit or a robotic processing automation system".
It would have been obvious to one having ordinary skill in the art at the effective filling date of the invention to integrate the licensing control as taught in Cella and apply that to event management system as taught in Conlan. Motivation to do so comes from the same rationale as outlined above with respect to Claim 1.
Claim 5
As to Claim 5, Conlan combined with Cella, Hwan and Cobb teaches all the limitations of Claim 1 as discussed above.
Cella teaches:
The system of claim 1, wherein the respective set of club requirements for at least one of the approved sanctions requires the event to include a club-specific award;
As outlined above, Cella gives us significant leeway as it pertains to the terms of the smart contract. Integration of a reward in the terms of the smart contract is outlined in [0326], "Thus an allocation of rewards may be provided as a consideration within the context of a loan or agreement. Systems may be utilized to allocate rewards. The allocation of rewards in various forms may be included where discussing a particular behavior, or encouragement of a particular behavior, without limitation. An allocation of a reward may include an actual dispensation of the award, and/or a recordation of the reward. The allocation of rewards may be performed by a smart contract circuit or a robotic processing automation system".
Cella does not teach:
wherein the respective set of club requirements for the at least one of the approved sanctions specify a set of eligibility requirements for exhibitors to be allowed to compete for the club-specific award; wherein the back-end system is configured to prevent exhibitors from registering to compete for the club-specific award unless the exhibitors satisfy the set of eligibility requirements.
However, Conlan teaches:
wherein the respective set of club requirements for the at least one of the approved sanctions specify a set of eligibility requirements for exhibitors to be allowed to compete for the club-specific award; wherein the back-end system is configured to prevent exhibitors from registering to compete for the club-specific award unless the exhibitors satisfy the set of eligibility requirements.
In [0050], "Referring once again to the example of FIG. 2, the participant registration engine 206 is intended to represent an engine that gathers information about participants and associated animals or devices, if applicable. In a specific implementation, registration can include entering multiple events (e.g., classes at a horse show in which a rider will compete). Initial registration information can be shared with a venue, used to autofill future registrations, used to stop cross-entries, used to prevent registration for events for which a participant is ineligible". We see this specifically integrated with respect to regulating awards(in this case the capturing of points) with the requirement of association membership. [0051], " Associations (e.g., USEF, PCHA, NORCAL, OHJA) are tracked because they can sponsor multiple divisions and riders must be members of an association to capture points for sponsored division and class; association membership impacts eligibility to participate in classes, so riders are given a unique number from each association in which they have membership. In a specific implementation, individuals can readily see how many points are needed to qualify for medals through an API to a relevant association".
It would have been obvious to one having ordinary skill in the art at the effective filling date of the invention to integrate the licensing control as taught in Cella and apply that to event management system as taught in Conlan. Motivation to do so comes from the same rationale as outlined above with respect to Claim 1.
Claim 6
As to Claim 6, Conlan combined with Cella, Hwan and Cobb teaches all the limitations of Claim 1 as discussed above.
Cella teaches:
The system of claim 1, further comprising a third front-end system communicatively connected to the back-end system; the third front-end system configured to provide a graphical user interface for the set of clubs to register with the back-end system and process the applications for sanctions that are submitted by the data process system of the back-end system.
In [0512], "In embodiments, the compliance system 13800 may provide a graphical user interface that allows users to create smart contracts governing personality rights licenses. In these embodiments, the compliance system allows a user (e.g., a licensor) to select a smart contract template. In some embodiments, the compliance system 13800 may restrict the user to only select a smart contract template that is associated with an institution of the licensor". Given the notion of supporting users and associated information, we consider the limitation of registration to be inherently enclosed. In [0513], "In embodiments, the compliance system 13800 may provide a graphical user interface to verify performance of an obligation by a licensor. In some of these embodiments, the compliance system 13800 may include an application that is accessed by licensors, that allows a licensor to prove that he or she performed an obligation".
It would have been obvious to one having ordinary skill in the art at the effective filling date of the invention to integrate the licensing control as taught in Cella and apply that to event management system as taught in Conlan. Motivation to do so comes from the same rationale as outlined above with respect to Claim 1.
Claim 7
As to Claim 7, Conlan combined with Cella, Hwan and Cobb teaches all the limitations of Claim 1 as discussed above.
Cella teaches:
The system of claim 1, further comprising a third front-end system communicatively connected to the back-end system; the third front-end system configured to provide a graphical user interface for the set of clubs to register with the back-end system;
In [0512], "In embodiments, the compliance system 13800 may provide a graphical user interface that allows users to create smart contracts governing personality rights licenses. In these embodiments, the compliance system allows a user (e.g., a licensor) to select a smart contract template. In some embodiments, the compliance system 13800 may restrict the user to only select a smart contract template that is associated with an institution of the licensor". Given the notion of supporting users and associated information, we consider the limitation of registration to be inherently enclosed.
the third front-end system configured to provide each of the set of clubs, from which approved sanctions were purchased, access the respective the custom report of the finalized results generated for the club by the data processing system.
In [0513], "In embodiments, the compliance system 13800 may provide a graphical user interface to verify performance of an obligation by a licensor. In some of these embodiments, the compliance system 13800 may include an application that is accessed by licensors, that allows a licensor to prove that he or she performed an obligation. In some of these embodiments, the application may allow a user to record locations that the licensor went to (e.g., locations of film or photo shoots), to upload records (e.g., screen shots of social media posts) or to provide other corroborating evidence that the licensor has performed his or her obligations with respect to a licensing transaction. In this way, the licensor can prove that he or she performed the tasks required by the licensing deal. In some embodiments, the application may interact with a wearable device or may capture other digital exhaust, such as social media posts of the user (e.g., licensor) to collect evidence that supports or disproves a licensor's claim that he or she performed the obligations under the transaction agreement. In embodiments, the corroborating evidence collected by the application may be recorded by the application and stored on the distributed ledger as a licensor datastore 13856C". Given the broadest reasonable interpretation of this claim, we construe the generation of a customized report according to club requirements to analogize to the data processing system's generation of a report as an obligation of the creditor - it is provided that corroborating evidence may be recorded by the application and stored on the distributed ledger, accessible through a graphic user interface. Again, the logic for creating that customized reported can be found in [0515], "In embodiments, the compliance system 13800 is configured to perform analytics and provide reports to a regulatory body and/or other entities (e.g., the other organizations)". An alternate feature of the invention discloses in [0450], " May generate a set of data record that define the facility or a set of facilities under common ownership or operation by a host. The data record may have any suitable schema...May generate content, such as a document, message, alert, report, webpage and/or application page based on the contents of the data record".
It would have been obvious to one having ordinary skill in the art at the effective filling date of the invention to integrate the licensing control as taught in Cella and apply that to event management system as taught in Conlan. Motivation to do so comes from the same rationale as outlined above with respect to Claim 1.
Claim 8
As to Claim 8, Conlan combined with Cella, Hwan and Cobb teaches all the limitations of Claim 1 as discussed above.
Cella teaches:
The system of claim 1, further comprising a third front-end system communicatively connected to the back-end system; the third front-end system configured to provide a graphical user interface for the set of clubs to register with the back-end system;
In [0905], " In some embodiments, the knowledge distribution system 16802 may include an account management system. In embodiments, the account management system 16846 may facilitate creation and/or storage of user accounts related to users of the knowledge distribution system 16802, the knowledge distribution system 16802, and/or the distributed ledger 16808. For example, the account management system 16846 may be configured to facilitate registration of one or more of the knowledge providers 16806, the knowledge recipients 16818, the crowdsourcers 16836, and/or other third parties that may be associated with the knowledge distribution system 16802, the knowledge distribution system 16802, and/or the distributed ledger 16808".
Cella does not teach:
wherein for at least one club of the set of clubs, the data processing system is configured to track and maintain results and standings for members of the at least one club;
However, Conlan teaches:
wherein for at least one club of the set of clubs, the data processing server is configured to track and maintain results and standings for members of the at least one club;
In [0052], "Point and award updates are later associated with registrants. Points and awards are associated with riders for each class for each association. Points are totaled by class for awards in a division. Associations have unique point value systems. Each rider is linked to multiple associations and each association has a member number."
Conlan teaches:
wherein the third front-end system configured to provide the members of the at least one club access to the results and standings for members of the at least one club.
In [0051], "Associations (e.g., USEF, PCHA, NORCAL, OHJA) are tracked because they can sponsor multiple divisions and riders must be members of an association to capture points for sponsored division and class; association membership impacts eligibility to participate in classes, so riders are given a unique number from each association in which they have membership. In a specific implementation, individuals can readily see how many points are needed to qualify for medals through an API to a relevant association". In [0052], "Point and award updates are later associated with registrants. Points and awards are associated with riders for each class for each association. Points are totaled by class for awards in a division. Associations have unique point value systems. Each rider is linked to multiple associations and each association has a member number".
It would have been obvious to one having ordinary skill in the art at the effective filling date of the invention to integrate the licensing control as taught in Cella and apply that to event management system as taught in Conlan. Motivation to do so comes from the same rationale as outlined above with respect to Claim 1.
Claim 9
As to Claim 9, Conlan combined with Cella, Hwan and Cobb teaches all the limitations of Claim 1 as discussed above.
Cella teaches:
The system of claim 1, wherein the second front-end system is configured to permit the exhibitors to initiate electronic payment for the registration using the back-end system.
In [0068] of Conlan, "FIG. 12 is a diagram 1200 of an example of a system for show office management. The diagram 1200 includes a scratch engine 1202, a competition management kiosk 1204, a show management engine 1206, and a show venue datastore 1208...In operation, a competitor pays for a competition class but may be unable to participate in the class, so they need to cancel (and therefore are not responsible for paying for the class) '. In [0069] of Conlan, " The competition kiosk 1204 is intended to represent engines and devices to be located within a competition office to assist with signup and other activities. In a specific implementation, the competition kiosk 1204 allows trainers to login using unique IDs, select a rider they want to scratch, confirm the rider is in the class to be scratched, confirm competition time has not passed (because you typically can't scratch a class that has already started), scratch the rider (triggering an engine of the competition kiosk 1204 to initiate a refund or credit". Given the requirement of exhibitors to pay for registration, as well as the disclosed ability to process refunds and the existence of a billing component, we look to Cella for payment processing architecture, in [0033], "The smart contract action may be one of an assignment of a serial number to the object that is 3D printed... verifying payment and/or transfer of the tokenized digital knowledge...performing one or more operations with respect to the distributed ledger, and creating one or more new blocks in the distributed ledger. The smart contract action may include...payment received or currency transferred from a knowledge recipient device of the knowledge recipient, and transfer of the tokenized digital knowledge to the knowledge recipient device".
It would have been obvious to one having ordinary skill in the art at the effective filling date of the invention to integrate the licensing control as taught in Cella and apply that to event management system as taught in Conlan. Motivation to do so comes from the same rationale as outlined above with respect to Claim 1.
Claim 10
As to Claim 10, Conlan combined with Cella, Hwan and Cobb teaches all the limitations of Claim 1 as discussed above.
Conlan teaches:
The system of claim 1, wherein the user interface provided by the second front- end system is a web-based application executed on a personal electronic device.
In [0072], "FIG. 13 is a screenshot 1300 of an example of an event list interface. As shown, the event list interface can display different events, and users can register to event(s), and/or add new event(s)". Examining the figure, it's clear that the interface is executed as a web-based application. In [0060], " FIG. 9 is an image 900 of a screenshot 902 on a smartphone that displays an interface for adding and scratching classes. The screenshot 902 includes a ring selector graphical object 904, class graphical objects 906, and a menu bar 910". Given the context of staggered start times, we can interpret each of these classes to be distinct events.
Claim 11
As to Claim 11, Conlan combined with Cella, Hwan and Cobb teaches all the limitations of Claim 1 as discussed above.
Conlan teaches:
The system of claim 1, wherein the user interface provided by the second front- end system is a local application
In [0050], "Referring once again to the example of FIG. 2, the participant registration engine 206 is intended to represent an engine that gathers information about participants and associated animals or devices, if applicable... Initial registration information can be shared with a venue, used to autofill future registrations, used to stop cross-entries, used to prevent registration for events for which a participant is ineligible, or the like, if applicable. In a horse show context, such information can include rider name (though a restriction on showing the last name of a minor may be enforced, assuming names are shared), rider association number(s), address, phone number, email, date of birth/age (note: show age changes December 1), and horse info (e.g., name, age, height, association number)". In [0072], "FIG. 13 is a screenshot 1300 of an example of an event list interface. As shown, the event list interface can display different events, and users can register to event(s), and/or add new event(s)". In [0022], "Software in a computer system is typically stored in non-volatile storage. Indeed, for large programs, it may not even be possible to store the entire program in memory. For software to run, if necessary, it is moved to a computer-readable location appropriate for processing, and for illustrative purposes in this paper, that location is referred to as memory. Even when software is moved to memory for execution, a processor will typically make use of hardware registers to store values associated with the software, and a local cache that, ideally, serves to speed up execution. As used herein, a software program is assumed to be stored at an applicable known or convenient location (from non-volatile storage to hardware registers) when the software program is referred to as “implemented in a computer-readable storage medium.” A processor is considered “configured to execute a program” when at least one value associated with the program is stored in a register readable by the processor". In [0026], "An engine can include hardware, firmware, or software embodied in a computer-readable medium for execution by the processor".
Conlan does not teach:
downloaded onto a personal electronic device.
However, Cella teaches:
downloaded onto a personal electronic device.
In [0895], " In some scenarios, knowledge recipient 16818 may employ a plurality of knowledge recipient devices 16894, such as a server or computing device configured to download one or more instances of digital knowledge 16804 from the distributed ledger 16808 and transmit the one or more instances of digital knowledge to a 3D printer, a factory machine, a manufacturing system, or some other suitable device for using the one or more instances of the digital knowledge 16804".
It would have been obvious to one having ordinary skill in the art at the effective filling date of the invention to integrate the licensing control as taught in Cella and apply that to event management system as taught in Conlan. Motivation to do so comes from the same rationale as outlined above with respect to Claim 1.
Claim 12
As to Claim 12, Conlan combined with Cella, Hwan and Cobb teaches all the limitations of Claim 1 as discussed above.
Conlan teaches:
The system of claim 1, wherein on the back-end system is configured to receive scoring data for the exhibitors from a set of judges and store the scoring data the database; wherein the back-end system is configured to determine the finalized results from the received scoring data.
In [0080], "In some implementations, horse riders and/or horses can be linked to judges (e.g., in the same manner as the linking of horses and horse riders). This may facilitate real-time scoring and allowing accurate tracking of which judge scored which horses and/or horse riders". In [0088], "In step 1702, a system (e.g., the system for event management depicted in FIG. 1) receives a physical score card to be completed. In step 1704, the system generates and uploaded an electronic score card based on the physical score card to be completed. In step 1706, the system receives, via a graphical user interface, one or more user inputs drawn on the electronic score card. In step 1708, the system converts the one or more user inputs into usable data for scoring any of the first horse rider and the first horse. In step 1710, the system determines, based on the converted inputs, a rider score, thereby proving near-real time rider scoring. In step 1712, the system provides, in response to determining the rider score, the rider score to at least the first horse rider". In [0063], "FIG. 11 is an image 1100 of a screenshot 1102 on a smartphone that displays an interface a trainer can use at a horse show. The image 1100 is similar to the image 1000 but illustrates options, illustrated by way of example with options window 1104, available to a person using an interface like that illustrated in the screenshot 1102. The options window 1104 includes, by way of example, “my data,” “my sponsors,” “my team,” checkout, “my points,” placings, add, and scratch options. The “my data” option of the options window 1104 is intended to represent an interface to data associated with a competitor, trainer, or other user".
Claim 13
As to Claim 10, Conlan combined with Cella, Hwan and Cobb teaches all the limitations of Claim 1 as discussed above.
Conlan teaches:
The system of claim 1, wherein on the back-end system is configured to receive scoring data for the exhibitors from a set of judges and store the scoring data the database; wherein the back-end system is configured to determine the finalized results from the received scoring data;
In [0080], "In some implementations, horse riders and/or horses can be linked to judges (e.g., in the same manner as the linking of horses and horse riders). This may facilitate real-time scoring and allowing accurate tracking of which judge scored which horses and/or horse riders". In [0088], "In step 1702, a system (e.g., the system for event management depicted in FIG. 1) receives a physical score card to be completed. In step 1704, the system generates and uploaded an electronic score card based on the physical score card to be completed. In step 1706, the system receives, via a graphical user interface, one or more user inputs drawn on the electronic score card. In step 1708, the system converts the one or more user inputs into usable data for scoring any of the first horse rider and the first horse. In step 1710, the system determines, based on the converted inputs, a rider score, thereby proving near-real time rider scoring. In step 1712, the system provides, in response to determining the rider score, the rider score to at least the first horse rider". In [0063], "FIG. 11 is an image 1100 of a screenshot 1102 on a smartphone that displays an interface a trainer can use at a horse show. The image 1100 is similar to the image 1000 but illustrates options, illustrated by way of example with options window 1104, available to a person using an interface like that illustrated in the screenshot 1102. The options window 1104 includes, by way of example, “my data,” “my sponsors,” “my team,” checkout, “my points,” placings, add, and scratch options. The “my data” option of the options window 1104 is intended to represent an interface to data associated with a competitor, trainer, or other user".
wherein the judges provide the scoring data to the back-end system using a web-based application executed on personal electronic devices.
In [0074], "FIG. 15 is a diagram 1500 of an example of a score card to be completed. In some implementations, a process scan and/or upload a PDF (or other electronic format) of an existing score card (e.g., made of paper, card stock and/or other computer-scannable material) into a computer system to be delivered wirelessly to a plurality of mobile and stationary devices. Then users of the application may be able to provide user inputs (e.g., draw) on the PDF. The user inputs may include, for example, a variety of figures, type, or numbers. Once the user has finished drawing on top of the PDF picture, a button can allow the user to send their completed form to one or many other people through either email or through the system. In some implementations, the system has two columns integrated with the PDF whereby the numbers drawn on the PDF are converted into usable data for the system. This may allow, for example, the data to be processed by the system to provide near-real time rider scoring. The system can pull the data from the PDF to send real time updates of scores". In [0026], "A computer system can be implemented as an engine, as part of an engine, or through multiple engines". In [0027], "The engines described in this paper, or the engines through which the systems and devices described in this paper can be implemented, can be cloud-based engines. As used in this paper, a cloud-based engine is an engine that can run applications and/or functionalities using a cloud-based computing system. All or portions of the applications and/or functionalities can be distributed across multiple computing devices and need not be restricted to only one computing device. In some embodiments, the cloud-based engines can execute functionalities and/or modules that end users access through a web browser or container application without having the functionalities and/or modules installed locally on the end-users' computing devices".
It would have been obvious to one having ordinary skill in the art at the effective filling date of the invention to integrate the licensing control as taught in Cella and apply that to event management system as taught in Conlan. Motivation to do so comes from the same rationale as outlined above with respect to Claim 1.
Claim 14
As to Claim 14, Conlan combined with Cella, Hwan and Cobb teaches all the limitations of Claim 1 as discussed above.
Conlan teaches:
The system of claim 1, wherein on the back-end system is configured to receive scoring data for the exhibitors from a set of judges and store the scoring data the database; wherein the back-end system is configured to determine the finalized results from the received scoring data;
In [0080], "In some implementations, horse riders and/or horses can be linked to judges (e.g., in the same manner as the linking of horses and horse riders). This may facilitate real-time scoring and allowing accurate tracking of which judge scored which horses and/or horse riders". In [0088], "In step 1702, a system (e.g., the system for event management depicted in FIG. 1) receives a physical score card to be completed. In step 1704, the system generates and uploaded an electronic score card based on the physical score card to be completed. In step 1706, the system receives, via a graphical user interface, one or more user inputs drawn on the electronic score card. In step 1708, the system converts the one or more user inputs into usable data for scoring any of the first horse rider and the first horse. In step 1710, the system determines, based on the converted inputs, a rider score, thereby proving near-real time rider scoring. In step 1712, the system provides, in response to determining the rider score, the rider score to at least the first horse rider". In [0063], "FIG. 11 is an image 1100 of a screenshot 1102 on a smartphone that displays an interface a trainer can use at a horse show. The image 1100 is similar to the image 1000 but illustrates options, illustrated by way of example with options window 1104, available to a person using an interface like that illustrated in the screenshot 1102. The options window 1104 includes, by way of example, “my data,” “my sponsors,” “my team,” checkout, “my points,” placings, add, and scratch options. The “my data” option of the options window 1104 is intended to represent an interface to data associated with a competitor, trainer, or other user".
wherein web-based application is hosted by the first front-end system.
In [0076], "In step 1602, a system (e.g., the system for event management depicted in FIG. 1) obtains rider locations for a plurality of horse riders of a horse show event". This is explicitly disclosed to interface with a graphical user interface In [0083], " In step 1610, the system provides an interface (e.g., graphical user interface) through which the first route and the second route are accessible (e.g., viewable, editable, and/or otherwise interactable). For example, the interface can include a first graphical layer overlaid over a second graphical layer. The first layer can be a dynamic layer and the second graphical layer can be a static map". In [0026], "A computer system can be implemented as an engine, as part of an engine, or through multiple engines". In [0027], "The engines described in this paper, or the engines through which the systems and devices described in this paper can be implemented, can be cloud-based engines. As used in this paper, a cloud-based engine is an engine that can run applications and/or functionalities using a cloud-based computing system. All or portions of the applications and/or functionalities can be distributed across multiple computing devices and need not be restricted to only one computing device. In some embodiments, the cloud-based engines can execute functionalities and/or modules that end users access through a web browser or container application without having the functionalities and/or modules installed locally on the end-users' computing devices".
Claims 15-18 are rejected under 35 U.S.C. 103 as being unpatentable over Conlan(US 20210012293 A1) in view of Hwan(KR20180046979A) in further view of Cobb(US 6582231 B1).
Claim 15
As to Claim 15,
Conlan teaches:
A system for creation and management of animal exhibition events, comprising: a back-end system; the back-end system having a database; the back-end system having a data processing system;
In [0019], “FIG. 1 is a diagram 100 of an example of a system for event management. The diagram 100 includes a computer-readable medium (CRM) 102, a virtual venue datastore 104 coupled to the CRM 102, a venue mapping engine 106 coupled to the CRM 102, a fixture placement engine 108 coupled to the CRM 102, a dynamic location overlay engine 110 coupled to the CRM 102, a resource integration engine 112 coupled to the CRM 102, a resource tracking engine 114 coupled to the CRM 102, an environmental conditions estimation engine 116 coupled to the CRM 102, and an agent interface engine 118 coupled to the CRM 102.”
a first front-end system communicatively connected to the back-end system; the first front-end system configured to provide a graphical user interface for an event host to create and configure an event
In [0076], "In step 1602, a system (e.g., the system for event management depicted in FIG. 1) obtains rider locations for a plurality of horse riders of a horse show event". This is explicitly disclosed to interface with a graphical user interface In [0083], " In step 1610, the system provides an interface (e.g., graphical user interface) through which the first route and the second route are accessible (e.g., viewable, editable, and/or otherwise interactable). For example, the interface can include a first graphical layer overlaid over a second graphical layer. The first layer can be a dynamic layer and the second graphical layer can be a static map".
wherein the data processing system is configured to maintain configuration information for the event in the database
In [0031], "The virtual venue datastore 104 is intended to represent a datastore of static and dynamic objects within a venue, which can include places, people, animals, and things that can be tracked in some manner (e.g., via manual methods, such as checklists, or via sensors located around a venue, including cameras that can use facial recognition to determine a location of a person, or radios that can detect RFID or other electromagnetic signals of devices, such as RFID tags affixed to an object or a wireless signal from a smartphone) or for which a location and time are otherwise provided. Static objects can include buildings, ski resorts, outdoor arenas, bodies of water, competition rings, tracks (including waypoints along a track), show grounds, tables, booths, entrances, exits, and other places or fixtures". In [0046], "Depending upon implementation-, configuration-, or preference-specific factors, dynamic venue maps can include, historic venue maps, a current venue map, and future venue maps. If an event is ongoing, one of the dynamic venue maps will be a current venue map and the others can be historic venue maps (if an event is over) or future venue maps (if an event has not yet begun)".
a second front-end system communicatively connected to the back-end system; the second front-end system configured to provide a graphical user interface for exhibitors to register for the event; wherein the data processing system is configured to maintain registration information for the exhibitors for the event in the database;
In [0050], "Referring once again to the example of FIG. 2, the participant registration engine 206 is intended to represent an engine that gathers information about participants and associated animals or devices, if applicable... Initial registration information can be shared with a venue, used to autofill future registrations, used to stop cross-entries, used to prevent registration for events for which a participant is ineligible, or the like, if applicable. In a horse show context, such information can include rider name (though a restriction on showing the last name of a minor may be enforced, assuming names are shared), rider association number(s), address, phone number, email, date of birth/age (note: show age changes December 1), and horse info (e.g., name, age, height, association number)". In [0072], "FIG. 13 is a screenshot 1300 of an example of an event list interface. As shown, the event list interface can display different events, and users can register to event(s), and/or add new event(s)".
the second front end system configured to provide a graphical user interface that displays a respective check-in /check-out sheet for the exhibitors indicating information for animals the exhibitor registered to bring to the event;
In [0050], "Referring once again to the example of FIG. 2, the participant registration engine 206 is intended to represent an engine that gathers information about participants and associated animals or devices, if applicable. In a specific implementation, registration can include entering multiple events (e.g., classes at a horse show in which a rider will compete). We consider the check-in/checkout sheet to be the information that the engine associates with a registered horse, which would encapsulate attendance at an event among various other information. Such information is graphically displayed in Fig. 5, see [0055], “FIG. 5 provides an example of event attendance management for a horse show context. FIG. 5 is a screenshot 500 of an example of an event participant status listing and management interface. Riders (competitors) are listed “in line” waiting to compete with a next in line to compete is highlighted and ready to be dragged “on course.” After a competitor is done, the competitor can be dragged to “done.” In an alternative, an event coordinator could automate the status update using location tracking. For example, a competitor with an RFID tag that is detected at the entrance to a course could cause the system to update status to “on course” automatically, making it unnecessary to drag-and-drop or perform some other manual interaction to accomplish the status change”.
Conlan does not teach:
wherein the second front-end system is configured to permit a first one of the exhibitors to initiate a transaction for sale of at least one animal they registered to bring to the event to a second one of the exhibitors for a specified amount;
However, Hwan teaches:
wherein the second front-end system is configured to permit a first one of the exhibitors to initiate a transaction for sale of at least one animal they registered to bring to the event to a second one of the exhibitors for a specified amount;
In [0010], " a terminal used by a horse seller who wishes to sell a horse, the horse seller terminal registering a horse specification sheet containing information about the horse and a horse riding video taken while the rider is riding the horse, in a horse transaction mediation server". In [0012], " a horse transaction payment unit that performs horse transaction payment processing by receiving the final horse purchase price or horse winning bid price from the horse buyer".
wherein in response to the transaction being initiated, the data processing system is configured to electronically transfer payment for the specified amount from the second one of the exhibitors to the first one of the exhibitors
In [0012], "a horse transaction payment unit that performs horse transaction payment processing by receiving the final horse purchase price or horse winning bid price from the horse buyer and depositing it into the horse seller's financial account".
Conlan combined with Hwan does not teach:
and update the respective check-in /check-out sheets for the first one of the exhibitors and the second one of the exhibitors to indicate the sale of the at least one animal, wherein in response to completing the transfer payment, the graphical user interface of the second front end system is configured to update the respective check-in /check-out sheets for the first one of the exhibitors and the second one of the exhibitors to remove the at least one animal from the check-in/check-out of the first one of the exhibitors and add the at least one animal to the check-in/check-out of the second one of the exhibitors.
However, Cobb teaches:
and update the respective check-in /check-out sheets for the first one of the exhibitors and the second one of the exhibitors to indicate the sale of the at least one animal, wherein in response to completing the transfer payment, the graphical user interface of the second front end system is configured to update the respective check-in /check-out sheets for the first one of the exhibitors and the second one of the exhibitors to remove the at least one animal from the check-in/check-out of the first one of the exhibitors and add the at least one animal to the check-in/check-out of the second one of the exhibitors.
Understanding the relational database information to analogize to check-in and check-out sheets in Col 11, Lines 48-63, “In completing the ownership transfer recordation application 70 the parties fill in the seller's name and phone number and the date of sale, the new owner's name address and phone number and both parties sign the document in the spaces provided. The certificate 51 provides instructions instructing the seller or purchaser to provide or record a microchip number for the animal if not done previously. Upon receipt of the certificate 51 with the completed ownership transfer recordation application 70, the registry changes records the new information concerning the identity of the new owner of the animal in the relational database and enters a microchip number if provided and not previously entered in the relational database. The registry then prints a new certificate of registration 51 providing the identifying information for the new owner and sends the new certificate of registration 51 to the listed owner”.
Conlan discloses a system for managing a horse exhibition. Cobb discloses a system for facilitating conveyances of ownership to people participating in animal transactions. Extending the system for facilitating horse transactions as recorded in Hwan and the system for managing ownership information of Cobb to the system for horse exhibition management as mentioned in Conlan is applicable as Conlan already provides support for horse buyers and sellers – see [0042] of Conlan; the only thing missing is the means for actually facilitating the transactions.
It would have been obvious to one having ordinary skill in the art at the effective filling date of the invention to combine the horse transaction management as taught in Hwan and apply that to the event management software as taught in Conlan . Motivation to do so comes from the fact that the claim is plainly directed to the predictable result of combining known items in the prior art, with the expected benefit that adopting the transaction infrastructures of Hwan and Cobb would enable users to streamline the purchasing and sale of horses.
Claim 16
As to Claim 16, Conlan combined with Hwan and Cobb teaches all the limitations of Claim 15 as discussed above.
Hwan teaches:
The system of claim 15, wherein in initiation of the transaction, the first one of the exhibitors uses the second front-end system to input or select an identifier for the at least one animal and input or select an identifier for the second one of the exhibitors.
In [0013], "When a horse purchase request is received from the horse purchaser terminal, the horse transaction brokerage department provides contact information between the horse seller and the horse purchaser to broker the horse purchase transaction so that the horse purchase price can be negotiated, and when a horse auction participation is received from the horse purchaser terminal, the horse auction transaction can be brokered by deciding the horse seller and the horse purchaser who has offered the highest price as the successful bidder". In [0061], "The member information storage unit (320) is a database that stores member information of horse sellers and horse buyers. Accordingly, the name, address, contact information, business registration number, ID, and password of each horse seller may be stored, and the name, address, contact information, business registration number, ID, and password of each horse buyer may be stored".
It would have been obvious to one having ordinary skill in the art at the effective filling date of the invention to combine the horse purchasing system as taught in Hwan and apply that to event management system of Conlan. Motivation to do so comes from the same rationale as outlined above with respect to Claim 1.
Claim 17
As to Claim 17, Conlan combined with Hwan and Cobb teaches all the limitations of Claim 15 as discussed above.
Conlan teaches:
The system of claim 15, wherein the second front-end system is configured to provide each of the exhibitors access to the respective check-in /check-out sheet generated for the exhibitor.
In [0059], "FIG. 8 is an image 800 of a screenshot 802 on a smartphone that displays horse information. The screenshot 802 includes a horse information panel 804, a people information panel 806, an pictures panel 808, and a menu bar 810. The horse information panel 804 displays information about the horse, including show name, breed, birthday, sex, trainer, barn, points (for the horse), and a for sale indicator. Other information could include height, association numbers, HippoMundo Integration options, competition results, vet records, ownership trace, or the like. The people information panel 806 displays information about people associated with the horse, including rider, veterinary, trainer, and points (for the trainer)".
Claim 18
As to Claim 18, Conlan combined with Hwan and Cobb teaches all the limitations of Claim 15 as discussed above.
Conlan teaches:
The system of claim 1, wherein the user interface provided by the second front- end system is a web-based application executed on a personal electronic device.
In [0072], "FIG. 13 is a screenshot 1300 of an example of an event list interface. As shown, the event list interface can display different events, and users can register to event(s), and/or add new event(s)". Examining the figure, it's clear that the interface is executed as a web-based application. In [0060], " FIG. 9 is an image 900 of a screenshot 902 on a smartphone that displays an interface for adding and scratching classes. The screenshot 902 includes a ring selector graphical object 904, class graphical objects 906, and a menu bar 910". Given the context of staggered start times, we can interpret each of these classes to be distinct events.
Claims 19 are rejected under 35 U.S.C. 103 as being unpatentable over Conlan(US 20210012293 A1) in view of Hwan(KR20180046979A) in further view of Cobb(US 6582231 B1) in further view of Cella(US 20210342836 A1)
Claim 19
As to Claim 19, Conlan combined with Hwan and Cobb teaches all the limitations of Claim 15 as discussed above.
Conlan teaches:
The system of claim 15, wherein the user interface provided by the second front- end system is a local application
In [0050], "Referring once again to the example of FIG. 2, the participant registration engine 206 is intended to represent an engine that gathers information about participants and associated animals or devices, if applicable... Initial registration information can be shared with a venue, used to autofill future registrations, used to stop cross-entries, used to prevent registration for events for which a participant is ineligible, or the like, if applicable. In a horse show context, such information can include rider name (though a restriction on showing the last name of a minor may be enforced, assuming names are shared), rider association number(s), address, phone number, email, date of birth/age (note: show age changes December 1), and horse info (e.g., name, age, height, association number)". In [0072], "FIG. 13 is a screenshot 1300 of an example of an event list interface. As shown, the event list interface can display different events, and users can register to event(s), and/or add new event(s)". In [0022], "Software in a computer system is typically stored in non-volatile storage. Indeed, for large programs, it may not even be possible to store the entire program in memory. For software to run, if necessary, it is moved to a computer-readable location appropriate for processing, and for illustrative purposes in this paper, that location is referred to as memory. Even when software is moved to memory for execution, a processor will typically make use of hardware registers to store values associated with the software, and a local cache that, ideally, serves to speed up execution. As used herein, a software program is assumed to be stored at an applicable known or convenient location (from non-volatile storage to hardware registers) when the software program is referred to as “implemented in a computer-readable storage medium.” A processor is considered “configured to execute a program” when at least one value associated with the program is stored in a register readable by the processor". In [0026], "An engine can include hardware, firmware, or software embodied in a computer-readable medium for execution by the processor".
Conlan does not teach:
downloaded onto a personal electronic device.
However, Cella teaches:
downloaded onto a personal electronic device.
In [0895], " In some scenarios, knowledge recipient 16818 may employ a plurality of knowledge recipient devices 16894, such as a server or computing device configured to download one or more instances of digital knowledge 16804 from the distributed ledger 16808 and transmit the one or more instances of digital knowledge to a 3D printer, a factory machine, a manufacturing system, or some other suitable device for using the one or more instances of the digital knowledge 16804".
Conlan combined with Hwan and Cobb discloses a system for managing a horse exhibition. Extending the control of licensing allowed for by Cella is applicable to Conlan because we already have means for associations sponsoring different events – see [0051] of Conlan. Adding means to regulate the provision and conditions of such sponsorships, derived from Cella, would be applicable to Conlan’s event management architecture.
It would have been obvious to one having ordinary skill in the art at the effective filling date of the invention to combine the horse transaction management as taught in Hwan and the licensing control of Cella and apply that to the event management software as taught in Conlan combined with Hwan and Cobb. Motivation to do so comes from the fact that the claim is plainly directed to the predictable result of combining known items in the prior art, with the expected benefit that adopting the licensing control of Cella would give sponsoring associations the means to intelligently specify their needs and wants as it pertains to granting sanctions.
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Conlan(US 20210012293 A1) in view of Cella(US 20210342836 A1).
Claim 20
As to Claim 20,
Conlan teaches:
A system for management of events, comprising: a back-end system; the back-end system having a database; the back-end system having a data processing system;
In [0019], “FIG. 1 is a diagram 100 of an example of a system for event management. The diagram 100 includes a computer-readable medium (CRM) 102, a virtual venue datastore 104 coupled to the CRM 102, a venue mapping engine 106 coupled to the CRM 102, a fixture placement engine 108 coupled to the CRM 102, a dynamic location overlay engine 110 coupled to the CRM 102, a resource integration engine 112 coupled to the CRM 102, a resource tracking engine 114 coupled to the CRM 102, an environmental conditions estimation engine 116 coupled to the CRM 102, and an agent interface engine 118 coupled to the CRM 102.”Conlan does not teach:
a first front-end system communicatively connected to the back-end system, the first front-end system configured to provide a graphical user interface for an event host to create and configure an event and select a set of clubs the event host would like to sanction the event; wherein in response to the set of clubs being selected via the graphical user interface provided by the first front-end system, the data processing system submits applications for purchase of sanctions from the set of clubs for the event; wherein the data processing system is configured to track approval status of the applications for purchase of sanctions in the database; wherein the data processing system is configured to store respective sets of club requirements for approved sanctions of the set of sanction sanctions in the database;
However, Cella teaches:
a first front-end system communicatively connected to the back-end system, the first front-end system configured to provide a graphical user interface for an event host to create and configure an event and select a set of clubs the event host would like to sanction the event; wherein in response to the set of clubs being selected via the graphical user interface provided by the first front-end system, the data processing system submits applications for purchase of sanctions from the set of clubs for the event; wherein the data processing system is configured to track approval status of the applications for purchase of sanctions in the database; wherein the data processing system is configured to store respective sets of club requirements for approved sanctions of the set of sanction sanctions in the database;
In [0512], "In embodiments, the compliance system 13800 may provide a graphical user interface that allows users to create smart contracts governing personality rights licenses...In embodiments, the graphical user interface allows a user to define certain terms (e.g., the type or types of obligations placed on the licensor, an amount of funds to paid, a date by which the obligations of the licensor must be completed by, a location at which the obligation is completed, and/or other suitable terms). Upon a user providing input for parameterizing a smart contract template, the compliance system 13800 may generate a smart contract by parameterizing one or more variables in the smart contract with the provided input. Upon parameterizing an instance of a smart contract, the compliance system 13800 may deploy the smart contract. In some embodiments, the compliance system 13800 may deploy the smart contract by broadcasting the parameterized smart contract to the participant nodes, which in turn may update each respective instance of the distributed ledger with the new smart contract. In some embodiments, an institution of the licensor must approve the parameterized smart contract before the parameterized smart contract may be deployed to the distributed ledger. In [0513], " In this way, the licensor can prove that he or she performed the tasks required by the licensing deal. In some embodiments, the application may interact with a wearable device or may capture other digital exhaust, such as social media posts of the user (e.g., licensor) to collect evidence that supports or disproves a licensor's claim that he or she performed the obligations under the transaction agreement. In embodiments, the corroborating evidence collected by the application may be recorded by the application and stored on the distributed ledger as a licensor datastore 13856C". Note that given the recordation of the fulfillment of the contract occurs on the blockchain, we understand its approval status to be discernible from such; the same applies with the terms of the contract.
Conlan teaches:
a second front-end system communicatively connected to the back-end system; the second front-end system configured to provide a graphical user interface for exhibitors to dynamically enter a competition during the event;
In [0050], "Referring once again to the example of FIG. 2, the participant registration engine 206 is intended to represent an engine that gathers information about participants and associated animals or devices, if applicable... Initial registration information can be shared with a venue, used to autofill future registrations, used to stop cross-entries, used to prevent registration for events for which a participant is ineligible, or the like, if applicable. In a horse show context, such information can include rider name (though a restriction on showing the last name of a minor may be enforced, assuming names are shared), rider association number(s), address, phone number, email, date of birth/age (note: show age changes December 1), and horse info (e.g., name, age, height, association number)". In [0072], "FIG. 13 is a screenshot 1300 of an example of an event list interface. As shown, the event list interface can display different events, and users can register to event(s), and/or add new event(s)".
a third front-end system communicatively connected to the back-end system; the third front-end system configured to provide a graphical user interface configured for a set of judges to view information on and enter scores for exhibitors entered as contestants in the competition;
In [0080], "In some implementations, horse riders and/or horses can be linked to judges (e.g., in the same manner as the linking of horses and horse riders). This may facilitate real-time scoring and allowing accurate tracking of which judge scored which horses and/or horse riders". In [0088], "In step 1702, a system (e.g., the system for event management depicted in FIG. 1) receives a physical score card to be completed. In step 1704, the system generates and uploaded an electronic score card based on the physical score card to be completed. In step 1706, the system receives, via a graphical user interface, one or more user inputs drawn on the electronic score card. In step 1708, the system converts the one or more user inputs into usable data for scoring any of the first horse rider and the first horse. In step 1710, the system determines, based on the converted inputs, a rider score, thereby proving near-real time rider scoring. In step 1712, the system provides, in response to determining the rider score, the rider score to at least the first horse rider". In [0063], "FIG. 11 is an image 1100 of a screenshot 1102 on a smartphone that displays an interface a trainer can use at a horse show. The image 1100 is similar to the image 1000 but illustrates options, illustrated by way of example with options window 1104, available to a person using an interface like that illustrated in the screenshot 1102. The options window 1104 includes, by way of example, “my data,” “my sponsors,” “my team,” checkout, “my points,” placings, add, and scratch options. The “my data” option of the options window 1104 is intended to represent an interface to data associated with a competitor, trainer, or other user".
wherein in response to the exhibitor being dynamically added to the competition via the second front-end system, the graphical user interface of the third front-end system is prompted to display the exhibitor as a contestant in the competition.
We understand the display of competitors to judges to be implicit based on the maintenance of tracking information, like other resources. In [0053], “An aspect of participant registration is integrating the participant as described above with reference to the resource integration engine 112 (FIG. 1). Upon registration, participants can be tracked like other resources, when the participant comes within range of a sensor or when the participant or an agent thereof otherwise provides location information”. Notably, it is given above in [0080] that real-time scoring
It would have been obvious to one having ordinary skill in the art at the effective filling date of the invention to combine the horse transaction management as taught in Hwan and the licensing control of Cella and apply that to the event management software as taught in Conlan. Motivation to do so comes from the fact that the claim is plainly directed to the predictable result of combining known items in the prior art, with the expected benefit as outlined above in Claim 1.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to THEODORE L XIE whose telephone number is (571)272-7102. The examiner can normally be reached M-F 9-5.
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, Rutao Wu can be reached at 571-272-6045. 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.
/THEODORE XIE/Examiner, Art Unit 3623
/CHARLES GUILIANO/Primary Examiner, Art Unit 3623