DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed 4/7/2026 has been entered.
The Office Action is in response to claims filed on 4/7/2026 where claims 1-20 are pending and ready for examination.
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.
Applicant's arguments filed 4/7/2026 have been read in their entirety and are not persuasive.
Applicant argues the Berger does not disclose that the request is based on the 2D barcode for event data, because the event data exists independently and the QR code merely provides access (on causality.
Applicant’s argument is not persuasive, Berger expressly teaches that scanning the QR code causes a user device to issue a request derived from the URL encoded int QR code, and the server responds with event data (See e.g. [0055]). Thus the request is directly based on the 2D barcode, and the response contains event data to be displayed, as recited.
Applicant’s argument is further not persuasive because it imports limitations not recited in the claim. The claim only requires that the request be based on the 2D barcode for event data to be displayed; It does not require that the 2D barcode define generate, or otherwise determine the event data itself. Accordingly, Applicant’s argument is not commensurate with the scope of the claims and is not afforded no patentable weight.
In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
The Examiner respectfully reminds the Applicant:
In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
Accordingly, Applicant’s arguments regarding the 35 USC 103 are not persuasive based on attacking individual references. As an example, the Applicant does not acknowledge that Bracken provides for a publicly viewable sign at any size [0012] and therefore the entire prior art rejection is based on “a publicly viewable sign at any size”
The Examiner respectfully reminds the Applicant that the claims and/or limitations are examined based upon the metes and bounds presented (MPEP 2171). The independent claims do not provide any restraints with respect to the size of the sign, the type of event, and where publicly the sign is displayed for viewing purposes. Accordingly, Applicant’s arguments directed to such unstated limitations are not commensurate with the scope of the claim and are afforded no patentable weight.
(A) the claims must set forth the subject matter that the inventor or a joint inventor regards as the invention; and [AltContent: rect]
(B) the claims must particularly point out and distinctly define the metes and bounds of the subject matter to be protected by the patent grant.
Accordingly the Examiner has maintained all previous prior art rejections. The Examiner has also furnished another 35 USC 102 rejection (Colomban; US 11379484) for the independent claims.
Claim Rejections - 35 USC § 103
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-3, 5-6, 8-9, 13, 15-16, and 18 are rejected under 35 USC 103 as being unpatentable over Deugo, “Using QR-Codes ford Attendance Tracking”, 2015 in view of Bracken (US 2012/0215571) and in further view of Berger (US 2011/0283196)
Regarding claim 1, An event management system, the system comprising:
a server system comprising an electronic processor, the server system configured to (Duego; Duego teaches a server which facilitates and/or coordinates event tracking;
see e.g. Page 7 “Our, working system has the following features. Ultimately attendance tracking is stored on our server ... we support the having a user scan up to 1000 QR codes ...”):
receive event data that is to be displayed on an end user device (Duego, Duego teaches the user of the event tracking system may input event based information that will be ultimately displayed on the user’s device ;
see e.g. Page 3, Section 3.1 QR Code Generation:
Students generate their QR Codes by going to our QR Code Generation website, as shown in Fig. 2. At the site their first step is to enter their relevant information ... For general events, there is also a comment filed included to collect other relevant data”
see e.g. Figures 1, 2);
generate a computer display format for the event data to be displayed (Duego; Duego teaches event data is formatted in particular manner for subsequent displaying on a user device;
see e.g. Page 5, Column 2, Fig. 9 illustrating the displaying of EVENT DATA “COMP:1601”A:2015:WINTER.):
receive event data that is to be printed (Duego; Duego teaches data associated with the event may be printed;
see e.g. Page 4, Column 1 “... hit the Print Your QR code button that will display the QR code on its own web page and initiate the corresponding browser’s printing functionality. One can print the QR code on a printer or print it as PDF file ... the QR Code can then be printed, emailed, or moved onto a student’s mobile device”);
generate a 2D barcode linking to the event data to be displayed (Duego ; Duego teaches the generation of QR barcodes
see e.g. Section 3.1 QR Code Generation “ ... QR Barcode Scanner App ...”
see e.g. Page 4, Column 1 “The QR code generation and its three steps provide a quick and easy approach for student to generated their individualized QR codes an be able to save them to disk or print them out. The next part of our approach is for students to bring their QR code to class in order for their attendance to be tracked):
Duego suggests but does not expressly disclose:
generate a printer file including the event data to be printed and the 2D barcode;
receive requests from user devices associated with different people, based on the 2D barcode, for the event data to be displayed; and
generate responses to the requests containing the event data to be displayed
a printer configured to receive the printer file from the server system and generate a publicly viewable sign including the event data to be printed and the 2D barcode.
However in analogous art Bracken discloses:
generate a printer file including the event data to be printed and the 2D barcode (Bracken; Bracken teaches printing a badge/sign including event data and a 2D barcode. The act of printing necessarily requires generation of a printer file (i.e., a print-ready data representation) comprising the event data and the 2D barcode prior to transmission to the printer;
see e.g. Fig 12 [0032] illustrating the printing of a paper printout (i.e. sign) comprising 2D barcode and event data;
see e.g. Fig.13 [0033], Fig. 14 [0034] and Fig. 15 [0035]
see e.g. [0042] “ ... print my badge .. the system generates a document 31 unique to that individual ...”
);
a printer configured to receive the printer file from the server system and generate a publicly viewable sign including the event data to be printed and the 2D barcode (Bracken;
see e.g. [0012] “... although badge size is not restricted when using the self-badging method of the invention, that is pre-screened/printed with logos, event name and/or other information that distinguishes the holder as unique to that specific meeting. When the holder is mated with the paper badge the credential is then valid for use at the meeting. The badge can be used for identification purposes and/or to validate entry in and out of events, social functions, etc.
see e.g. Fig 12 [0032] illustrating the printing of a paper printout (i.e. sign) comprising 2D barcode and event data;
see e.g. Fig.13 [0033], Fig. 14 [0034] and Fig. 15 [0035]
see e.g. [0042] “ ... print my badge .. the system generates a document 31 unique to that individual ...”
Because Bracken expressly teaches that badge size is not restricted, it would have been an obvious matter of design choice to scale the printed badge to a larger format (e.g. banner, sign, and/or flyer) to improve visibility to multiple attendees, thereby yielding a publicly viewable sign including the same event data and 2D barcode )
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Duego with Bracken’s printing scheme. The motivation being the combined solution provides for increased efficiencies in event management and coordination activities.
Duego in view of Bracken does not expressly disclose
receive requests from user devices associated with different people, based on the 2D barcode, for the event data to be displayed; and
generate responses to the requests containing the event data to be displayed
However in analogous art Berger discloses:
;
receive requests from user devices associated with different people, based on the 2D barcode, for the event data to be displayed; (Berger;
see e.g. [0004] Current online stationery services allow end users to select stationery for events such as wedding invitations, birth announcements, and baptism announcements. In addition, current online greeting card services allow users to select greeting cards for different occasions such as birthdays and holidays. These services typically print the stationery and/or greeting cards and mail them to the end user. The end user manually reviews the order and mails the printed stationery and/or greeting cards to the recipients.
see e.g. [0055] “... the URL 501 is printed with alphanumeric characters on the back of the stationery/card along with a QR code or other bar code format which may be scanned to link to the RSVP website ... the QR code and/or the URL may be shortened versions of the real URL and upon selecting the shortened version, the users web browser may be redirected by the online stationery service 10 to the actual URL of the RSVP website”
see e.g. [0052], [0057]
Berger ([0055]) expressly discloses that a QR code (a 2D barcode) is provided , and when scanned, the QR code causes the user’s browser to issue a request that links to the RSVP website. This request is necessarily based on the 2D barcode because the request originates from the URL encoded within the QR code. Once the request is sent , the server responds by directing the browser to the RSVP site. Paragraphs [0054] and [0056] further show that the RSVP server provides access to event data stored I its databases, including the RSVP responses, event information such as date/time/location, and comments which are then displayed to the user.
Thus Berger teaches that scanning the QR code is the trigger for generating a request to the server, and the server generates a response containing the event data to be displayed. The claim does not require that the vent data itself be embedded in the QR code; it requires only that the request be based on the 2D barcode. Berger squarely meets this requirement];
) and
generate responses to the requests containing the event data to be displayed (Berger;
see e.g. [0054] “ ... The RSVP response and other data related to the event 401 may be stored within the stationary services databases 115 and made accessible to the user (e.g. via web browser 145 of client 150) and/or to the invitees ...”
see e.g. [0056] “Regardless of how the invitees 451 link to the Web Pages 505 ... the invitees can access and modify various different types of event data .. the invitees may enter an RSVP response 550, review event information 551 ... and submit comments or other text related to the event 554 ...”
see e.g. [0051] “ .. design of RSVP response which allow invitees to specify whether they will be attending the event .. the online stationary service 100 prints ...”
The Examiner notes Berger provides merging of the Online Stational or Greeting Card Service embodiment with an RSVP System (see e.g. [0052], [0053])
The Examiner notes the Applicant’s specification is described within the context of an RSVP system (see e.g. Applicant’s specification [57])
)
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Berger’s RSVP scheme. The motivation being the combined solution provides for incorporating known techniques resulting in increased efficiencies of event management platforms.
Regarding claim 2, Duego in view of Bracken and in further view of Berger disclose the event management system of claim 1 wherein the display format is a webpage.
wherein the display format is a webpage (The combined solution per Berger provides for one of ordinary skill in the art to utilize webpages via Berger’s RSVP web pages;
see e.g. Berger [0055] “... RSVP service 400 includes a web page generation module 400 for dynamical generating a series of RSVP web pages ... the URL 501 is printed with alphanumeric characters on the back of the stationery/card along with a QR code or other bar code format which may be scanned to link to the RSVP website ... the QR code and/or the URL may be shortened versions of the real URL and upon selecting the shortened version, the users web browser may be redirected by the online stationery service 10 to the actual URL of the RSVP website)
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Berger’s RSVP scheme. The motivation being the combined solution provides for incorporating known techniques resulting in increased efficiencies of event management platforms
Regarding claim 3, Duego in view of Bracken and in further view of Berger disclose the event management system of claim 2, wherein the server system is configured to generate a webpage containing the event data to be displayed and send the webpage in response to receiving a request for the event data to be displayed (The combined invention per Berger.
see e.g. [0054] “... The RSVP response and other data related to the event 401 may be stored within the stationary services databases 115 and made accessible to the user (e.g. via web browser 145 of client 150) and/or to the invitees ...”
see e.g. [0056] “Regardless of how the invitees 451 link to the Web Pages 505 ... the invitees can access and modify various different types of event data .. the invitees may enter an RSVP response 550, review event information 551 ... and submit comments or other text related to the event 554 ...” see e.g. [0052], [0057) .
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Berger’s RSVP scheme. The motivation being the combined solution provides for incorporating known techniques resulting in increased efficiencies of event management platforms
Regarding claim 5, Duego in view of Bracken and in further view of Berger disclose the event management system of claim 1, wherein the server system is configured to
receive responses to the event data displayed in respone to a request based on a 2D barcode (The combined solution per Berger’s RSVP scheme;
see e.g. [0055] “... the URL 501 is printed with alphanumeric characters on the back of the stationery/card along with a QR code or other bar code format which may be scanned to link to the RSVP website ... the QR code and/or the URL may be shortened versions of the real URL and upon selecting the shortened version, the users web browser may be redirected by the online stationery service 10 to the actual URL of the RSVP website”
see e.g. [0054] “ ... The RSVP response and other data related to the event 401 may be stored within the stationary services databases 115 and made accessible to the user (e.g. via web browser 145 of client 150) and/or to the invitees ...”
see e.g. [0056] “Regardless of how the invitees 451 link to the Web Pages 505 ... the invitees can access and modify various different types of event data .. the invitees may enter an RSVP response 550, review event information 551 ... and submit comments or other text related to the event 554 ...”
see e.g. [0051] “ .. design of RSVP response which allow invitees to specify whether they will be attending the event .. the online stationary service 100 prints ...” see e.g. [0052],[0057]
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Berger’s RSVP scheme. The motivation being the combined solution provides for incorporating known techniques resulting in increased efficiencies of event management platforms.
Regarding claim 6, Duego in view of Bracken and in further view of Berger disclose the event management system of claim 5, wherein the displayed event data includes response requests, and the server system is configured to receive a response request and associate it with the displayed event data (The combined invention per Berger and Bracken provides the modification and/or editing of event data;
see e.g. [0054] “... The RSVP response and other data related to the event 401 may be stored within the stationary services databases 115 and made accessible to the user (e.g. via web browser 145 of client 150) and/or to the invitees ...”
see e.g. [0056] “Regardless of how the invitees 451 link to the Web Pages 505 ... the invitees can access and modify various different types of event data .. the invitees may enter an RSVP response 550, review event information 551 ... and submit comments or other text related to the event 554 ...” see e.g. [0052], [0057]
see e.g. Bracken [0040] “... allows the attendee to access their record and change/edit the information appearing on the badge”
see e.g. Bracken Fig. 12 illustrating the web page displaying event data)).
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Berger’s RSVP scheme. The motivation being the combined solution provides for incorporating known techniques resulting in increased efficiencies of event management platforms
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Duego with Bracken’s printing scheme. The motivation being the combined solution provides for increased efficiencies in event management and coordination activities.
Regarding claim 8, Duego in view of Bracken and in further view of Berger discloses the event management system of claim 1, Duego does not expressly disclose wherein the data content overlap between the event data to be printed and the event data to be displayed is less than 10 percent (This feature per the Office Action of 12/08/2022 is deemed as Applicant Admitted Prior Art. Therefor it would have been obvious to one of ordinary skill in the art to incorporate this feature. The motivation being the combined solution provides for implementing a known technique providing for system optimization.).
Regarding claim 9, Duego in view of Bracken and in further view of Berger disclose the event management system of claim 8, Duego does not expressly disclose wherein there is no overlap in data content between the event data to be printed and the event data to be displayed ((This feature per the Office Action of 12/08/2022 is deemed as Applicant Admitted Prior Art. Therefor it would have been obvious to one of ordinary skill in the art to incorporate this feature. The motivation being the combined solution provides for implementing a known technique providing for system optimization).
Regarding claim 13, claim 13 comprises the same and/or similar subject matter as claim 1 and is considered an obvious variation; therefore it is rejected under the same rationale.
Regarding claim 15, Duego in view of Bracken and in further view of Berger disclose the method of claim 13, wherein the displayed event data includes response requests, and further comprising receiving responses to event data displayed in response to a request based on a 2D barcode and associating it with the displayed event data (The combined solution per Berger;
see e.g. [0054] “... The RSVP response and other data related to the event 401 may be stored within the stationary services databases 115 and made accessible to the user (e.g. via web browser 145 of client 150) and/or to the invitees ...”
see e.g. [0056] “Regardless of how the invitees 451 link to the Web Pages 505 ... the invitees can access and modify various different types of event data .. the invitees may enter an RSVP response 550, review event information 551 ... and submit comments or other text related to the event 554 ...” see e.g. [0052], [0055].[0057]
Regarding claim 16, claim 16 comprises the same and/or similar subject matter as claim 7 and is considered an obvious variation; therefore it is rejected under the same rationale.
Regarding claim 18, claim 18 comprises the same and/or similar subject matter as claim 9 and is considered an obvious variation; therefore it is rejected under the same rationale.
Claim 4 is rejected under 35 USC 103 as being unpatentable over Duego in view of Bracken and in further view of Berger and in further view of Tamanimi (US 10,270,771)
Regarding claim 4, Duego in view of Bracken and in further view of Berger disclose the event management system of claim 1, and although Duego teaches (QR Barcodes, see e.g. Section 3.1 “... QR Barcode ...”), Duego does not expressly disclose wherein the 2D barcode encodes a Uniform Resource Locator.
However in analogous art Tamanimi discloses:
wherein the 2D barcode encodes a Uniform Resource Locator (Tamanimi; Tamanimi teaches encoding URLs into QRs and barcodes;
see e.g. Column 20, Line 56 – Column 21, Line 5 “ ... generate a graphic pattern 818 that encodes a uniform resource locator (URL) ... the graphic pattern 818 may include a QR code, a barcode, a string of letters/number, or any other visual information ...”)
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Duego with Tamanimi’s URL encoding scheme. The motivation being the combined solution provides for increased efficiencies in event management and coordination activities.
Claims 7 and 17 are rejected under 35 USC 103 as being unpatentable over Duego in view of Bracken and in further view of Berger and in further view of Aoki (US 2002/0063693)
Regarding claim 7, Duego in view of Bracken and in further view of Berger disclose the event management system of claim 1, Duego does not expressly disclose wherein the event data to be printed has less than 10 percent of the data content of the event data to be displayed.
However in analogous art Aoki discloses:
determining portions (e.g. percentages) of text to be printed (Aoki
see e.g. [0119] “... in the event that the preview data is made up of multiple sets of data, the user can specify portions thereof to be printed in particular (trimming). In the event that trimming is performed, the data printing execution request containing the request for printing the specified portion is transmitted to the data output control terminal”)
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Duego with Aoki’s printing scheme. The motivation being the combined solution provides for one of ordinary skill in the art to intelligently control portions of percentages of datasets to be presented resulting in the ability to implement particular percentage ranges.
Duego in view of Bracken and in further view of Berger and in further view of Aoki disclose:
wherein the event data to be printed has less than 10 percent of the data content of the event data to be displayed (The combined solution per Aoki provide for manipulation of the event data set to be printed (e.g. Bracken, Fig. 12) to realize a 10% amount).
Regarding claim 17, claim 17 comprises the same and/or similar subject matter as claim 7 and is considered an obvious variation; therefore it is rejected under the same rationale.
Claims 10 and 19 are rejected under 35 USC 103 as being unpatentable over Duego in view of Bracken and in further view of Berger and in further view of Grubb (US 5,272,623)
Regarding claim 10, Duego in view of Bracken and in further view of Burger disclose the event management system of claim 1, wherein the server system, in response to a request for the event data to be displayed based on the 2D barcode, is configured to generate a response containing a portion of the event data to be displayed and asking for personal data from an end user associated with the request (The combined invention per Bracken and/or Berger provides for a user to edit user information associated with the event which can be facilitated by conventional menus and/or categories to provide manipulating portions of data)
see e.g. Bracken [0041] “When the attendee/exhibitor, chooses “edit my badge” they are automatically directed to their registration record where they may edit the fields of data that display on the badge ...”
Berger:
see e.g. [0055] “... the URL 501 is printed with alphanumeric characters on the back of the stationery/card along with a QR code or other bar code format which may be scanned to link to the RSVP website ... the QR code and/or the URL may be shortened versions of the real URL and upon selecting the shortened version, the users web browser may be redirected by the online stationery service 10 to the actual URL of the RSVP website”
see e.g. [0054] “ ... The RSVP response and other data related to the event 401 may be stored within the stationary services databases 115 and made accessible to the user (e.g. via web browser 145 of client 150) and/or to the invitees ...”
see e.g. [0056] “Regardless of how the invitees 451 link to the Web Pages 505 ... the invitees can access and modify various different types of event data .. the invitees may enter an RSVP response 550, review event information 551 ... and submit comments or other text related to the event 554 ...”
see e.g. [0051] “ .. design of RSVP response which allow invitees to specify whether they will be attending the event .. the online stationary service 100 prints ...” see e.g. [0052],[0057]
).
.As evidence of the rational above, Grubb discloses:
displaying portions of user data for configuration (Grubb; Grubb teaches the utilization of conventional menu lists comprising categories of user data for users to configure data;
see e.g. Column 27, Lines 27 - 29“... user data input along with user selection in relation to separate menu lists of categories ...”
see e.g. Abstract “... user provides input data as well as from the data base selects categories and selective answers questions ...”)
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Duego with Grubb’s menus. The motivation being the combined invention provides for increased efficiencies with respect to users providing portions of data.
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Berger’s RSVP scheme. The motivation being the combined solution provides for incorporating known techniques resulting in increased efficiencies of event management platforms
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Duego with Bracken’s printing scheme. The motivation being the combined solution provides for increased efficiencies in event management and coordination activities.
Regarding claim 19, claim 19 comprises the same and/or similar subject matter as claim 10 and is considered an obvious variation; therefore it is rejected under the same rationale.
Claims 11 and 20 are rejected under 35 USC 103 as being unpatentable over Duego in view of Bracken and in further view of Berger and in further view of Grubb and in further view of Duff (US 2012/0191735)
Regarding claim 11, Duego in view of Bracken and in further view of Berger and in further view of Grubb disclose the event management system of claim 10, wherein the server system is further configured to receive a response containing personal data from an end user (The combined invention provides for inputting and/or modifying user data associated with the event; see e.g. Bracken [0041] “ ... edit my badge ...”), however the combined solution does not provide for validation of the data and therefore does not expressly disclose determine whether the personal data is valid, and generate a response containing the rest of the event data to be displayed if the personal data is valid.
However in analogous art Duff discloses:
determine whether the personal data is valid, and generate a response containing the rest of the event data to be displayed if the personal data is valid (Duff; Duff teaches validating user input data with conventional response;
see e.g. [0109] “... validates the update data against one or more cells within the user session data table ... verification that update data complies with a data validation mask”
see e.g. [0071] “... second request 215 may be appropriately validated ...”
see e.g. [0087] “... pursuant to successful validatin, the update data 215A may be written into updateable cell 290B ... host organization 110 further receives the second request 215 from the client device 106A behaving update data 215A therein and the host organization 110 further a) validates the update data 215A against the one or more cells ... an error message may responsively be generated and the write/update/modification will fail ...”
see e.g. [0097 “ ... Validation may include verifying that update data corresponds to an updateable field or cell within the user session data table, or verifying that update data complies with a validation mask corresponding to the target location of the update data”).
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Duego with Duff’s validation scheme. The motivation being the combined invention provides for increased efficiencies in managing event data.
Regarding claim 20, claim 20 comprises the same and/or similar subject matter as claim 11 and is considered an obvious variation; therefore it is rejected under the same rationale.
Claim 12 is rejected under 35 USC 103 as being unpatentable over Duego in view of Bracken and in further view of Berger and in further view of Valentine (US 2017/0116893)
Regarding claim 12, Duego in view of Bracken and in further view of Berger disclose the event management system of claim 1, although the combined invention per Bracken provides for utilizing various types of paper to print the sign and subsequently insert it into a plastic badge holder (see e.g. [0034], [0035]), the combined solution does not expressly disclose wherein the sign is composed of corrugated plastic.
However in analogous art Valentine discloses:
wherein the sign is composed of corrugated plastic (Valentine. Valentine teaches within the context of conferences and/or events teaches the utilization of several readily available materials including corrugated plastic;
see e.g. [0016] “... tradeshow, convention, corporate event, sporting event, conference, exhibition, general event ...”
see e.g. [0019] “... The display may be made from any material known in the art that will become known in the art, including ... plastic (e.g. corrugate plastic) ...”)
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Duego with Valentine’s display material (i.e. corrugated plastic) The motivation being the combined solution provides for a more durable badge and provides a pathway for larger signs to be printed for particular sessions at a conference where conference participants could scan a large corrugated plastic sign comprising all of the conference event data explicitly taught by Duego in view of Bracken.
Claim 12 is rejected under 35 USC 103 as being unpatentable over Duego in view of Bracken and in further view of Berger and in further view of O’Connor (US 2015/0056599)
Regarding claim 12, Duego in view of Bracken and in further view of Berger disclose the event management system of claim 1, although the combined invention per Bracken provides for utilizing various types of paper to print the sign and subsequently insert it into a plastic badge holder (see e.g. [0034], [0035]), the combined solution does not expressly disclose wherein the sign is composed of corrugated plastic.
However in analogous art O’Connor discloses:
wherein the sign is composed of corrugated plastic (O’Connor; O’Connor teaches within the context of conferences and/or events the utilization of corrugated plastic to realize a container (e.g. badge)
see e.g. [0066] “Fig. 6 illustrates a frontal view of an embodiment of the present invention, namely a special form of notebook which features a double corrugated plastic rail or overlay, allowing the notebook to have depth creating a container”)
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Duego with O’Connor’s display material (i.e. corrugated plastic) The motivation being the combined solution provides for a more durable badge.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1 and 13 are rejected under 35 USC 102(a)(2) as being anticipated by Colomban (US 11,379,484), Filed July 24, 2021.
Regarding claim 1, Colomban discloses an event management system, the system comprising:
a server system comprising an electronic processor, the server system configured to: (Colomban; see e.g. Fig. 9 illustrating server (901) comprising processor (904
see e.g. Column 23, Lines 53 – 53 “... server ...”; Colum 24, Lines 33 – 37 “... processor” ...):
receive event data that is to be displayed on an end user device (Colomban; Colomban teaches receiving event details (i.e. event data) from an organizer of an event which is rendered on the organizer’s user device;
see e.g. Column 4, Lines 26 - 35 “... The media acquisition system receives 101 registration and event details from an organizer of the event. In various embodiments, the media acquisition system receives the event details through a webpage via a browser application, or through a standalone application on an electronic device of the organizer, or through electronic mail (email), or through a graphical user interface (GUI) that the media acquisition system renders on the electronic device of the organizer ...”
see e.g. Fig. 1, Step 101 “RECEIVE REGISTRATION AND EVENT DETAILS FROM AN ORGANIZER OF THE EVENT”);
generate a computer display format for the event data to be displayed (Colomban; Colomban teaches templates (i.e. display formats) which provides for displaying event data;
see e.g. Column 4, Lines 46 - 57 “... The media acquisition system renders a number of event type templates for different types of events to allow the organizer to provide the event details. The event type templates comprise, for example, wedding templates, birthday party templates, corporate event templates, graduation event templates, Independence Day templates, etc. The media acquisition system also allows the organizer to select a general template for providing the event details. The event type templates further comprise humorous templates, for example, templates that convey a message such as “congratulate me, I'm finally divorced!”);
receive event data that is to be printed (Colomban; Colomban teaches generating flyers that include event information thereby demonstrating that the received event details are used as data to be printed;
see e.g. Column 14, Lines 46-50 “... an event page for their wedding using the media acquisition system and print out flyers with scannable quick response (QR) codes to leave on each table at a venue for the event...”
see e.g. Column 15, Line 64 – Column 16, Line 2 “... The flyer 301 comprises a shareable link generated by the media acquisition system to provide attendees of the event access to the online portal exemplarily illustrated in FIG. 2. The flyer 301 comprises design elements 302, an image 303 that corresponds to the event ...”
see e.g. Fig. 3 illustrating Flyer 301 with event data previously received.
The recited “event data” encompasses event-related information received from the organizer, where at least a portion of the event data is used for display and it least a portion is used for printing, as supported by the disclosure);
generate a 2D barcode linking to the event data to be displayed (Colomban; Colomban teaches generating a 2D barcode (e.g. a QR code) that links directly to an online portal, where the online portal is accessible to users and portrays event information associated with the event;
see e.g. Column5, Line 57 – Column 6, Lines 25 “ The media acquisition system generates 103 a shareable link to the generated online portal in multiple formats for rendering the generated shareable link to the attendees of the event. The shareable link comprises information on the location of the online portal on the network. The formats of the shareable link to the generated online portal comprise, for example, a uniform resource locator (URL), an optical label such as a QR Code® or a barcode, ... For example, the media acquisition system allows the organizer to generate optical labels such as QR Codes® or barcodes ...”
see e.g. Column 2, Lines 30 – 47 “The media acquisition system generates 102 an online portal specific to the event and the organizer based on the received registration and event details with media request elements. The online portal is accessible over a network to the organizer and to users with information on the location of the online portal on the network. The generated online portal comprises editing tools for portrayal of event information and a selection of multiple layouts to showcase the event to visitors of the online portal. The visitors of the online portal are, for example, the attendees of the event. The editing tools allow portrayal of the event information, for example, as text in a selection of fonts, sizes, and styles such as varied typography, shapes of parts of textual content, effects including shadows, outlines, color, etc., or as audio clippings, videos, images, animation, augmented reality (AR) and/or virtual reality (VR) objects, custom visual effects, etc., or any combination thereof. The generated online portal provides a selection of multiple layouts to arrange data of the event information in a way deemed fit or appealing by the organizer of the event”);
generate a printer file including the event data to be printed and the 2D barcode (Colomban; Colomban teaches printing flyers that include event data and a QR code (see e.g. Fig. 3), and generating such printed output necessarily requires generation of a printer file including the event data to be printed and the QR code
see e.g. Column 16, Lines 8 – 10 “... Copies of the generated flyer 301 are printed from the media acquisition system and distributed to the attendees of the wedding event, for example, through placement of the flyers 301 at tables reserved for the attendees at a banquet hall where the wedding ceremony is conducted ...”
see e.g. Column 14, Lines 46-50 “... an event page for their wedding using the media acquisition system and print out flyers with scannable quick response (QR) codes to leave on each table at a venue for the event...”
see e.g. Column 15, Line 64 – Column 16, Line 2 “... The flyer 301 comprises a shareable link generated by the media acquisition system to provide attendees of the event access to the online portal exemplarily illustrated in FIG. 2. The flyer 301 comprises design elements 302, an image 303 that corresponds to the event ...”);
receive requests from user devices associated with different people, based on the 2D barcode, for the event data to be displayed (Colomban; Colomban teaches that attendees of the event scan the QR code on the printed flyer using their user devices to access the online portal, where such scanning constitutes requests from user devices associated with different people for the event data to be displayed;
see e.g. Column 16, Lines 4 – 8 “ ... attendees to scan an inset optical label comprising the machine-readable optical code 305, for example, a quick response code (QR Code®) or a barcode to be directed to the generated online portal ...” ) and
generate responses to the requests containing the event data to be displayed (Colomban; Colomban teaches that, in response to the QR code scan the online portal serves a webpage to the user device that includes the event information, thereby generating response to the requests containing the event data to be displayed;
see e.g. Column 4, Lines 20 – 23 “... The media acquisition system provides a platform where a person attending an event is allowed, for example, to scan an optical label such as a quick response code (QR Code®), a barcode, etc., or access a uniform resource locator (URL) directly to be directed to a webpage on the Internet specific to the event ...”); and
a printer configured to receive the printer file from the server system and generate a publicly viewable sign including the event data to be printed and the 2D barcode (Colomban; Colomban teaches printing flyers and/or signs for attendees of the event which are publicly viewable and available that include the event data and the 2D barcode. The printing of these elements necessarily requires the function of a printer;
see e.g. Column 6, Lines 5 – 12 “... table sign-holder sizes, table assignment cards, flyers ...”
see e.g. Column 16, Lines 8 – 10 “... Copies of the generated flyer 301 are printed from the media acquisition system and distributed to the attendees of the wedding event, for example, through placement of the flyers 301 at tables reserved for the attendees at a banquet hall where the wedding ceremony is conducted ...”
see e.g. Column 14, Lines 46-50 “... an event page for their wedding using the media acquisition system and print out flyers with scannable quick response (QR) codes to leave on each table at a venue for the event...”
see e.g. Fig. 3 illustrating a publicly viewable sign which was printed using a printer);
PNG
media_image1.png
579
422
media_image1.png
Greyscale
Regarding claim 13, claim 13 comprises the same elements and functions as claim 1 and may be rejected based on the same rationale.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1 and 13 are rejected under 35 USC 102(a)(1) as being anticipated by Berger
Regarding claim 1,Berger discloses an event management system, the system comprising:
a server system comprising an electronic processor, the server system configured to (Berger; see e.g. Fig. 4 illustrating Online Stationery/Card service 100 residing on a conventional server system comprising an conventional electronic processor;
see e.g. [0091] “... server running on Linux ...”
see e.g. [0092] “... general purpose or special purpose processor ...”):
receive event data that is to be displayed on an end user device (Berger;
see e.g. Fig. 4 illustrating Event Data 401 being received via RSVP service 400;
see e.g. Fig. 5 illustrating Event Data 401 being received via RSVP 400 which may be readily displayed on Client Devices comprising Client 451 (recipient) or Client (host) 151;
see e.g. Fig. 5 illustrating Event Information 501
see e.g. [0056] “ ... event information 551 (e.g. date, time and location; ticket information ...” see e.g. [0056] “... event information 551])
see e.g. Fig. 14 illustrating Event Data 401 being received via RSVP service 400 which may be readily displayed on Client Devices 1400(s)
see e.g. [0054] “... RSVP responses and other data related to the event 401 may be stored within the stationery service databases 115 and made accessible to the user (e.g. via web browser 145 of client 150) and/or to the invitees ...”);
generate a computer display format for the event data to be displayed (Berger; Berger teaches the Online Stationary Service comprises a format Conversion;
see e.g. [0053] “... the RSVP service 400 may be executed within the online stationary/card/photo service 100 ... all of the features of the stationery service 100 ... select a particular stationery/card design template 135 ... for a particular event ... the underlying principles of the invention are not limited to any particular type of event ...”
see e.g. [0077] “ ... RSVP web pages 505 ...graphical objects around the RSCP web pages ...”
see e.g. [0035] “... selects and personalized a stationery design ...”
see e.g. [0037] “... formatted print job 155 on the online stationery service ...”
see e.g. [0050] “... theme, color, cards format, card size ...”
see e.g. [0051] “... design stationery for a particular event ... the stationary design may include the design of RSVP response cards ...”
see e.g. [0057] “... stationary card design ...”
);
receive event data that is to be printed (Berger; Berger teaches the reception of event data which is subsequently printed;
see e.g. [0056] “,,, the invitees can access and modify various different types of event data. For example, the invitees may enter an RSVP response 550, review event information 551 (e.g., date, time and location; ticket information) .. submit comments or other text related to the event 554 ...”
see e.g. [0053] “... transmitted to a print service 252 for printing ...”
see e.g. Fig. 4 illustrating Print Services 252
see e.g,.[0051] “.. the online stationary service 100 prints ...”
see e.g. [0055] “... the URL 501 is printed with alphanumeric characters on the back of the stationery/card along with a QR code or other bar code format which may be scanned to link to the RSVP website ...”
see e.g. [0057] “... a unique URL which includes alphanumeric characters related to the event ...”;
generate a 2D barcode linking to the event data to be displayed (Berger; Berger teaches the generation of a QR code or other bard code format for the RSVP system (i.e. comprising event data);
see e.g. [0055] “... RSVP service 400 includes a web page generation module 400 for dynamical generating a series of RSVP web pages ... the URL 501 is printed with alphanumeric characters on the back of the stationery/card along with a QR code or other bar code format which may be scanned to link to the RSVP website ... the QR code and/or the URL may be shortened versions of the real URL and upon selecting the shortened version, the users web browser may be redirected by the online stationery service 10 to the actual URL of the RSVP website”);
generate a printer file including the event data to be printed and the 2D barcode (Berger; A conventional printer file is inherently generated an present in order to fulfill conventional printing services;
see e.g. [0055] “... the URL 501 is printed with alphanumeric characters on the back of the stationery/card along with a QR code or other bar code format which may be scanned to link to the RSVP website ... the QR code and/or the URL may be shortened versions of the real URL and upon selecting the shortened version, the users web browser may be redirected by the online stationery service 10 to the actual URL of the RSVP website”);
receive requests from user devices associated with different people, based on the 2D barcode, for the event data to be displayed; (Berger;
see e.g. [0004] Current online stationery services allow end users to select stationery for events such as wedding invitations, birth announcements, and baptism announcements. In addition, current online greeting card services allow users to select greeting cards for different occasions such as birthdays and holidays. These services typically print the stationery and/or greeting cards and mail them to the end user. The end user manually reviews the order and mails the printed stationery and/or greeting cards to the recipients.
see e.g. [0055] “... the URL 501 is printed with alphanumeric characters on the back of the stationery/card along with a QR code or other bar code format which may be scanned to link to the RSVP website ... the QR code and/or the URL may be shortened versions of the real URL and upon selecting the shortened version, the users web browser may be redirected by the online stationery service 10 to the actual URL of the RSVP website”
see e.g. [0052], [0057]
Berger ([0055]) expressly discloses that a QR code (a 2D barcode) is provided , and when scanned, the QR code causes the user’s browser to issue a request that links to the RSVP website. This request is necessarily based on the 2D barcode because the request originates from the URL encoded within the QR code. Once the request is sent , the server responds by directing the browser to the RSVP site. Paragraphs [0054] and [0056] further show that the RSVP server provides access to event data stored I its databases, including the RSVP responses, event information such as date/time/location, and comments which are then displayed to the user.
Thus Berger teaches that scanning the QR code is the trigger for generating a request to the server, and the server generates a response containing the event data to be displayed. The claim does not require that the vent data itself be embedded in the QR code; it requires only that the request be based on tgeh 2D barcode. Berger squarely meets this requirement); and
generate responses to the requests containing the event data to be displayed (Berger;
see e.g. [0054] “ ... The RSVP response and other data related to the event 401 may be stored within the stationary services databases 115 and made accessible to the user (e.g. via web browser 145 of client 150) and/or to the invitees ...”
see e.g. [0056] “Regardless of how the invitees 451 link to the Web Pages 505 ... the invitees can access and modify various different types of event data .. the invitees may enter an RSVP response 550, review event information 551 ... and submit comments or other text related to the event 554 ...”
see e.g. [0051] “ .. design of RSVP response which allow invitees to specify whether they will be attending the event .. the online stationary service 100 prints ...”); and
a printer configured to receive the printer file from the server system and generate a publicly viewable sign including the event data to be printed and the 2D barcode (Berger;
see e.g. Abstract “... a print module to generate and transmit a print job for printing ... network address .. receiving the relationship responses ... ”
see e.g. [0037] “ ... formatted print job 155 on the online stationary service 100. The print service 152 then accesses the print job by selecting the hyperlink. Regardless of how the print job is accessed, at 215, the formatted print job 155 is transmitted to either an internal printer 151 or external print service”
see e.g. [0055] “... the URL 501 is printed with alphanumeric characters on the back of the stationery/card along with a QR code or other bar code format which may be scanned to link to the RSVP website ... the QR code and/or the URL may be shortened versions of the real URL and upon selecting the shortened version, the users web browser may be redirected by the online stationery service 10 to the actual URL of the RSVP website”;
see e.g. [0004] “Current online stationery services allow end users to select stationery for events such as wedding invitations, birth announcements, and baptism announcements. In addition, current online greeting card services allow users to select greeting cards for different occasions such as birthdays and holidays. These services typically print the stationery and/or greeting cards and mail them to the end user. The end user manually reviews the order and mails the printed stationery and/or greeting cards to the recipients”
Under the broadest reasonable interpretation Berger’s printed event materials (e.g. wedding invitations and announcements) constitute publicly viewable signage, as they are physical printed items presented to multiple attendees in connection with an event).
The Examiner notes Berger provides merging of the Online Stational or Greeting Card Service embodiment with an RSVP System (see e.g. [0052], [0053])
The Examiner notes the Applicant’s specification is described within the context of an RSVP system (see e.g. Applicant’s specification [57])
Regarding claim 13, claim 13 comprises the same elements and functions as claim 1 and may be rejected based on the same rationale.
Any inquiry concerning this communication or earlier communications from the Examiner should be directed to TODD L. BARKER whose telephone number is (571) 270 0257. The Examiner can normally be reached on Monday through Friday, 7:30am to 5:00pm.
If attempts to reach the Examiner by telephone are unsuccessful, the Examiner's supervisor Vivek Srivastava can be reached on (571) 272 7304.
/TODD L BARKER/Primary Examiner, Art Unit 2449
