DETAILED ACTION
Acknowledgements
The amendment filed 2/5/2026 is acknowledged.
Claims 1-20 are pending.
Claims 1-20 have been examined.
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 .
Continued Examination Under 37 CFR 1.114
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 on 2/5/2026 has been entered.
Response to Amendment/Arguments
Regarding the rejection of the claims under 35 USC 101, applicant states that the claims cannot be characterized as reciting a fundamental economic practice or method of organizing human activity as they require a distributed computing architecture with two distinct servers that perform different roles, and a client-side security component that executes on a mobile user device. Applicant states that this is not a business method or commercial interaction, and therefore does not fall into any of the categories of abstract ideas. Further, applicant states the claims integrate any abstract idea into a practical application because they require separation of concerns across distinct servers and are directed to a method of federated token transfer, which addresses the technical challenge of securely transferring and managing digital tokens and credentials across multiple servers and devices in a federated environment. Applicant states that the recited steps address authentication challenges in distributed systems, enable secure, federated transfer of tokens without exposing sensitive information, and ensure that token credentials are periodically updated, mitigating risks of screenshot copying or duplication. Applicant states that the claims recite significantly more than an abstract idea because they recite a specific implementation that improves the security and functionality of token management in distributed computing environments, is not routine or conventional, and demonstrates a technical solution to a technical problem.
Examiner notes, however, that claim 15 recites “receive a credential corresponding a credential owner from [a user],” “validate that the credential owner has ownership of a token corresponding to an event, wherein validating comprises transmitting . . . a request to a primary token [authority] to authenticate the credential and the token and receiving, . . . from the primary token [authority], an authentication response indicating that the credential and the token are authenticated,” “[receive] the token from the primary token [authority],” “generate a . . . address that provides access to a certificate corresponding to the token and to a security component,” and “transmit the . . . address to the [user] corresponding to the credential owner.” These steps or functions describe a process of receiving a credential of a user, validating that the user owns a ticket to an event by communicating with a ticket issuer, obtaining the ticket, and generating and providing an identifier or address that allows the user to gain access to the ticket. Because this process of verifying a user’s ownership of a ticket to an event and providing them with the necessary information to access the ticket. This is a commercial interaction, and thus falls within the “certain methods of organizing human activity” grouping of abstract ideas. The claims do not include any technical features or technical improvements to federated token transfer, nor do they recite any technical features directed to improving security of token management in distributed computing environments. Although the claim describes the ticket as a token, the claimed steps are directed to verifying ownership of the ticket and providing a user with access to the ticket. The use of a primary and secondary token server, as well as a user device to perform the steps does not provide a practical application or significantly more than the abstract idea, because this only involves using computers as tools to automate and/or implement the abstract idea. The primary and secondary token servers only perform the steps that are part of the abstract idea. Additionally, regarding the client-side security component that executes on a mobile user device, the language “wherein the security component comprises executable software instructions that are delivered by the secondary token server to the mobile computing device via content referenced by the network address and that, when executed by a processor of the mobile computing device, cause the mobile computing device to rotate the certificate at a predetermined time interval, including rotating the certificate locally on the mobile computing device without network connectivity after provisioning” describes the use of a security component on a mobile computing device, while the claims are directed to a system comprising the primary and secondary token servers. This limitation describes functionality that occurs outside the scope of the claims because neither the primary nor the secondary token server is performing any of the functionality recited in this limitation, and the claims do not encompass the mobile computing device. Therefore, this limitation recites intended use language and does not require any steps or functionality to be performed within the scope of the claim. Accordingly, it does not provide a practical application or significantly more than the abstract idea.
Regarding the rejection of the claims under 35 USC 103, applicant states that the cited references do not disclose the claimed primary and secondary server architecture, and specifically, that Shore does not disclose the primary and secondary servers. Examiner notes, however, that Shore discloses a separate eTicket server (or “ticketdownload.com system” and “Immtec server” (See ¶ 102 and Figure 1a, items 770 and 750), where the ticketdownload.com server communicates with the Immtec server to validate security data (See Shore ¶ 195). Therefore, Shore discloses the primary and secondary servers.
Further, applicant states that the references also do not disclose certificate rotation on the user device. However, examiner notes that SafeTix discloses this feature (SafeTix p. 1, paragraph starting “Built on the Present platform . . .”; p. 2 paragraph starting “Later this year, fans . . .”).
Additionally, applicant specifically states that SafeTix does not disclose local, offline certificate rotation. Examiner notes that SafeTix does disclose local certificate rotation because the rotation occurs on the user’s device. Although SafeTix does not specifically disclose that the rotation occurs without network connectivity, these features do not gain patentable weight and do not serve to differentiate the claims from the prior art, because the language “wherein the security component comprises executable software instructions that are delivered by the secondary token server to the mobile computing device via content referenced by the network address and that, when executed by a processor of the mobile computing device, cause the mobile computing device to rotate a certificate at a predetermined time interval, including rotating the certificate locally on the mobile computing device without network connectivity after provisioning,” in claim 15 describes the use of a security component on a user’s mobile computing device, while the claim is directed to a system comprising a primary token server and secondary token server. This limitation describes functionality that occurs outside the scope of the claim because the primary or secondary token servers are not performing any of the functionality recited in this limitation, and the claim 15 does not encompass the mobile computing device. Therefore, this limitation recites intended use language and does not serve to differentiate the claim from the prior art. The recitation of the intended use of the claimed invention does not serve to differentiate the claim from the prior art. MPEP § 2103 I C states that language that suggests or makes optional but does not require steps to be performed or does not limit a claim to a particular structure does not limit the scope of a claim or claim limitation. An example of such language includes statements of intended use or field of use (MPEP §2103 I C).
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 15-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
In the instant case, claims 15-20 are directed to a system comprising a memory and a processor. Therefore, these claims fall within the four statutory categories of invention.
The claims recite receiving a user’s credential, determining that the user owns a valid ticket, obtaining the ticket, providing the user with an identifier that allows them to access the ticket and providing access to the ticket, which is an abstract idea. Specifically, the claims recite “receive a credential corresponding a credential owner from [a user],” “validate that the credential owner has ownership of a token corresponding to an event, wherein validating comprises transmitting . . . a request to a primary token [authority] to authenticate the credential and the token and receiving, . . . from the primary token [authority], an authentication response indicating that the credential and the token are authenticated,” “[receive] the token from the primary token [authority],” “generate a . . . address that provides access to a certificate corresponding to the token and to a security component,” and “transmit the . . . address to the [user] corresponding to the credential owner,” which is grouped within the “certain methods of organizing human activity” grouping of abstract ideas in prong one of step 2A of the Alice/Mayo test (MPEP 2106.04 & 2106.04(a)) because the claims describe a process that comprises receiving a credential of a user, validating that the user owns a ticket to an event by communicating with a ticket issuer, obtaining the ticket, and generating and providing an identifier or address that allows the user to gain access to the ticket. Because this process of verifying a user’s ownership of a ticket to an event and providing them with the necessary information to access the ticket is a commercial interaction, the claimed concept falls within the “certain methods of organizing human activity” grouping of abstract ideas. Accordingly, the claims recite an abstract idea (See MPEP 2106.04(a)).
This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A of the Alice/Mayo test (See MPEP 2106.04(d)), the additional elements of the claims such as the use of a primary token server, a secondary token server, a mobile device, a security component executing on the mobile device, and a network address, merely uses a computer as a tool to perform an abstract idea. Specifically, these additional elements perform the steps or functions of “receive a credential corresponding a credential owner from [a user],” “validate that the credential owner has ownership of a token corresponding to an event, wherein validating comprises transmitting . . . a request to a primary token [authority] to authenticate the credential and the token and receiving, . . . from the primary token [authority], an authentication response indicating that the credential and the token are authenticated,” “[receive] the token from the primary token [authority],” “generate a . . . address that provides access to a certificate corresponding to the token and to a security component,” and “transmit the . . . address to the [user] corresponding to the credential owner . . . .” Viewed as a whole, the use of a processor/computer as a tool to implement the abstract idea does not integrate the abstract idea into a practical application because it requires no more than a computer performing functions that correspond to acts required to carry out the abstract idea. Additionally, the language “wherein the security component comprises executable software instructions that are delivered by the secondary token server to the mobile computing device via content referenced by the network address and that, when executed by a processor of the mobile computing device, cause the mobile computing device to rotate the certificate at a predetermined time interval, including rotating the certificate locally on the mobile computing device without network connectivity after provisioning” describes the use of a security component on a mobile computing device, while the claims are directed to a system comprising the primary and secondary token servers. This limitation describes functionality that occurs outside the scope of the claims because neither the primary nor the secondary token server is performing any of the functionality recited in this limitation, and the claims do not encompass the mobile computing device. Therefore, this limitation recites intended use language and does not require any steps or functionality to be performed within the scope of the claim. The additional elements do not involve improvements to the functioning of a computer, or to any other technology or technical field (MPEP 2106.05(a)), and the claims do not apply or use the abstract idea in some other meaningful way beyond generally linking the use of the abstract idea to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP 2106.05(e) and Vanda Memo). Therefore, the claims do not, for example, purport to improve the functioning of a computer. Nor do they effect an improvement in any other technology or technical field. Accordingly, the additional elements do not impose any meaningful limits on practicing the abstract idea, and the claims are directed to an abstract idea.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when analyzed under step 2B of the Alice/Mayo test (See MPEP 2106.05), the additional elements of using the use of a primary token server, a secondary token server, a mobile device, a security component executing on the mobile device, and a network address to perform the steps only involves using a computer to automate and/or implement the abstract idea of receiving a user’s credential, determining that the user owns a valid ticket, obtaining the ticket, providing the user with an identifier that allows them to access the ticket and providing access to the ticket. As discussed above, taking the claim elements separately, these additional elements perform the steps or functions of “receive a credential corresponding a credential owner from [a user],” “validate that the credential owner has ownership of a token corresponding to an event, wherein validating comprises transmitting . . . a request to a primary token [authority] to authenticate the credential and the token and receiving, . . . from the primary token [authority], an authentication response indicating that the credential and the token are authenticated,” “[receive] the token from the primary token [authority],” “generate a . . . address that provides access to a certificate corresponding to the token and to a security component,” and “transmit the . . . address to the [user] corresponding to the credential owner . . .” These functions correspond to the actions required to perform the abstract idea. Viewed as a whole, the combination of elements recited in the claims merely recite the concept of receiving a user’s credential, determining that the user owns a valid ticket, obtaining the ticket, providing the user with an identifier that allows them to access the ticket and providing access to the ticket. Therefore, the use of these additional elements does no more than employ the computer as a tool to automate and/or implement the abstract idea. The use of a computer or processor to merely automate and/or implement the abstract idea cannot provide significantly more than the abstract idea itself (MPEP 2106.05 (f) & (h)). Additionally, the language “wherein the security component comprises executable software instructions that are delivered by the secondary token server to the mobile computing device via content referenced by the network address and that, when executed by a processor of the mobile computing device, cause the mobile computing device to rotate the certificate at a predetermined time interval, including rotating the certificate locally on the mobile computing device without network connectivity after provisioning” describes the use of a security component on a mobile computing device, while the claims are directed to a system comprising the primary and secondary token servers. This limitation describes functionality that occurs outside the scope of the claims because neither the primary nor the secondary token server is performing any of the functionality recited in this limitation, and the claims do not encompass the mobile computing device. Therefore, this limitation recites intended use language and does not require any steps or functionality to be performed within the scope of the claim. Accordingly, this language does not provide significantly more than the abstract idea. Therefore, the claim is not patent eligible.
Dependent claims 16-20 further describe the abstract idea of receiving a user’s credential, determining that the user owns a valid ticket, obtaining the ticket, providing the user with an identifier that allows them to access the ticket and providing access to the ticket. Specifically, claims 16-19 describe characteristics of the address, certificate, token, and security component, but do not require any steps or functions to be performed. Claims 20 further describes transferring the ticket to another user, which is directed to the abstract idea because it further describes the manner in which the user may use their ticket. The dependent claims do not include additional elements that integrate the abstract idea into a practical application or that provide significantly more than the abstract idea. Therefore, the dependent claims are also not patent eligible.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 8-14 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 8 is directed to “[a] non-transitory computer-readable medium storing instructions for” performing the steps recited in the claim. The recited steps of “receiving a credential . . .,” “validating that the credential owner has ownership of a token . . . and receiving, by the secondary token server . . . an authentication response . . . ,” “downloading, by the secondary token server . . .,” “generating . . .,” “transmitting the network address . . .,” and “transmitting the token . . .” are performed by the secondary token server, while the last step of “executing, by the security component a set of executable software instructions that are delivered by the secondary token server to the mobile computing device . . .” is performed by a security component that is located on the mobile computing device. Additionally, claim 11 and 12 also recite functions performed by the mobile computing device. The specification does not provide support for a single computer-readable medium storing instructions that can be used to carry out functionality on multiple separate and distinct devices, such as the secondary token server and the mobile computing device. The specification discloses that the user device and/or the system hardware can include a general purpose computer, and the computer may includes a computer-readable medium (See, e.g. Specification ¶¶ 16-17), but the specification does not describe a single computer-readable medium shared among multiple different computers such that instructions on the single medium can be used to carry out functionality that is performed by the multiple different computers, such as the secondary token server and the mobile computing device.
Claims 9-14 are also rejected as each depends on claim 8.
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 15-18 are rejected under 35 U.S.C. 103 as being unpatentable over Bergdale, et al. (US 2015/0294515) (“Bergdale”) in view of Shore (US 20140258011), “Ticketmaster Adds SafeTix™ Encrypted Tickets to Next Generation Access Control Platform”, May 15, 2019, available via Archive.org at https://business.ticketmaster.com/blog/ticketmaster-adds-safetix-encrypted-tickets-to-next-generation-access-control-platform/ (“SafeTix”), and Cocanougher, et al. (US 2022/0253755) (“Cocanougher”).
Regarding claim 15, Bergdale discloses a system comprising a primary token server having a stored token corresponding to a user account (Figure 27, ¶ 104); and a secondary token server, wherein the primary token server and the secondary token server are distinct server system, configured to:
receive a credential corresponding a credential owner from a mobile computing device (Bergdale ¶¶ 45, 51-52);
validate that the credential owner has ownership of a token corresponding to an event (Bergdale ¶¶ 45, 52);
generate an identifier that provides access to a certificate corresponding to the token and corresponding to a security component (Bergdale ¶¶ 45-46, 51-52, 70);
transmitting the identifier to the mobile computing device corresponding to the credential owner (Bergdale ¶¶ 45, 51-52).
Bergdale does not specifically disclose validating comprises transmitting, by the secondary token server, a request to a primary token server to authenticate the credential and the token and receiving, by the secondary token server from the primary token server, an authentication response indicating that the credential and the token are authenticated, or downloading, by the secondary token server, the token from the primary token server. Bergdale also does not specifically disclose generating a network address as the identifier, Bergdale also does not specifically disclose that the security component comprises executable software instructions that are delivered by the secondary token server to the mobile computing device via content referenced by the network address and that, when executed by a processor of the mobile computing device, cause the mobile computing device to rotate a certificate at a predetermined time interval, including rotating the certificate locally on the mobile computing device without network connectivity after provisioning.
Shore discloses that validating comprises transmitting, by the secondary token server a request to a primary token server to authenticate the credential and token and receiving, by the secondary token server, an authentication response from the primary token server, wherein the authentication response indicates that the credential and the token are authenticated by the primary token server based on the request (Shore ¶¶ 193-197, 199) and downloading, by the secondary token server, the token from the primary token server (Shore Figure 1F Step 1063; ¶¶ 74, 76).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify the method of Bergdale to include transmitting a request to a primary token server to authenticate the credential and token, receiving an authentication response from the primary token server, wherein the authentication response indicates that the credential and the token are authenticated by the primary token server based on the request, and downloading, by the secondary token server, the token from the primary token server, as disclosed in Shore, in order to allow a user to securely use electronic tickets by personally controlling their electronic tickets (Shore ¶ 6).
Bergdale in view of Shore does not specifically disclose generating a network address as the identifier. Bergdale in view of Shore also does not specifically disclose that the security component comprises executable software instructions that are delivered by the secondary token server to the mobile computing device via content referenced by the network address and that, when executed by a processor of the mobile computing device, cause the mobile computing device to rotate a certificate at a predetermined time interval, including rotating the certificate locally on the mobile computing device without network connectivity after provisioning.
SafeTix discloses a security component that comprises executable software instructions that, when executed by a processor of the mobile computing device, cause the mobile computing device to rotate a certificate at a predetermined time interval, including rotating the certificate locally on the mobile computing device (SafeTix p. 1, paragraph starting “Built on the Present platform . . .”; p. 2 paragraph starting “Later this year, fans . . .”).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify the method of Bergdale in view of Shore to include a security component a security component that comprises executable software instructions that, when executed by a processor of the mobile computing device, cause the mobile computing device to rotate a certificate at a predetermined time interval, including rotating the certificate locally on the mobile computing device, as disclosed in SafeTix, in order to protect against tickets being sold multiple times by unscrupulous resellers (SafeTix, p. 1, “These enhancements protect against tickets being screenshotted or photocopied and sold multiple times by unscrupulous resellers.”).
Further, regarding the language “wherein the security component comprises executable software instructions that are delivered by the secondary token server to the mobile computing device via content referenced by the network address and that, when executed by a processor of the mobile computing device, cause the mobile computing device to rotate a certificate at a predetermined time interval, including rotating the certificate locally on the mobile computing device without network connectivity after provisioning,” this describes the use of a security component on a user’s mobile computing device, while the claims are directed to a system comprising a primary token server and secondary token server. This limitation describes functionality that occurs outside the scope of the claims because the primary or secondary token servers are not performing any of the functionality recited in this limitation, and the claims do not encompass the mobile computing device. Therefore, this limitation recites intended use language and does not serve to differentiate the claims from the prior art. The recitation of the intended use of the claimed invention does not serve to differentiate the claim from the prior art. MPEP § 2103 I C states that language that suggests or makes optional but does not require steps to be performed or does not limit a claim to a particular structure does not limit the scope of a claim or claim limitation. An example of such language includes statements of intended use or field of use (MPEP §2103 I C). Accordingly, although Bergdale in view of SafeTix does not specifically disclose that the instructions are delivered by the secondary token server to the mobile computing device via content referenced by the network address, or that the instructions rotate the certificate without network connectivity after provisioning, these features do not gain patentable weight and do not serve to differentiate the claims from the prior art.
Bergdale in view of Shore and SafeTix does not specifically disclose generating a network address as the identifier.
Cocanougher discloses a network address as the identifier (Cocanougher ¶ 122).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify the method of Bergdale in view of Shore and SafeTix to include the use of a network address as the identifier, as disclosed in Cocanougher, in order to allow for automatic verification that a user holds a valid ticket for an event while allowing for the exchange and transfer of tickets (Cocanougher ¶¶ 10-11, 153).
Regarding claim 16, SafeTix discloses the security component as executable code (SafeTix p. 1, paragraph starting “Built on the Present platform . . .”; p. 2 paragraph starting “Later this year, fans . . .”).
Bergdale in view of Shore and SafeTix does not specifically disclose a network address that resolves to a webpage served by the secondary token server that displays the certificate generated from the token and includes the security component.
Cocanougher discloses a network address that resolves to a webpage served by the secondary token server that displays the certificate generated from the token (Cocanougher ¶¶ 50, 115, 122).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify the method of Bergdale in view of Shore and SafeTix to include a network address that resolves to a webpage served by the secondary token server that displays the certificate generated from the token, as disclosed in Cocanougher, in order to allow for automatic verification that a user holds a valid ticket for an event while allowing for the exchange and transfer of tickets (Cocanougher ¶¶ 10-11, 153).
Bergdale in view of Shore and SafeTix does not specifically disclose that the webpage includes the security component as executable code. However, this limitation describes a characteristic of the webpage, which is stored data. This particular characteristic of the webpage only describes data contained on the webpage and does not require any steps or functionality to be performed as part of the functionality of the claimed system. Therefore, this limitation recites nonfunctional descriptive material. When descriptive material is not functionally related to the substrate, the descriptive material will not distinguish the invention from prior art in terms of patentability. It has been held that where the printed matter is not functionally related to the substrate, the printed matter will not distinguish the invention from the prior art in terms of patentability …. [T]he critical question is whether there exists any new and unobvious functional relationship between the printed matter and the substrate (In re Ngai 367 F.3d 1336, 1339, 70 USPQ2d 1862 (Fed. Cir. 2004); Ex parte Nehls 88 USPQ2d 1883, 1888-1889 (BPAI 2008); In re Lowry, 32 USPQ2d 1031 (Fed. Cir. 1994); MPEP § 2111.05; Cf. In re Gulack, 703 F.2d 1381, 1385, 217 USPQ 401, 404 (Fed. Cir. 1983)). Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to include any type of information on the webpage, such as the security component as executable code, because the subjective interpretation of the information on the webpage does not patentably distinguish the claimed invention.
Regarding claim 17, Bergdale discloses that the certificate is a barcode or QR code (Bergdale ¶ 70).
Regarding claim 18, Bergdale discloses that the identifier is a downloadable package including the token and the security component (Bergdale ¶¶ 41, 45, 51-52).
Bergdale in view of Shore and SafeTix does not specifically disclose that the identifier is a network address.
Cocanougher discloses a network address as the identifier (Cocanougher ¶ 122).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify the method of Bergdale in view of Shore and SafeTix to include the use of a network address as the identifier, as disclosed in Cocanougher, in order to allow for automatic verification that a user holds a valid ticket for an event while allowing for the exchange and transfer of tickets (Cocanougher ¶¶ 10-11, 153).
Claims 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Bergdale in view of Shore, SafeTix, and Cocanougher as applied to claims 15 and 18 above, and further in view of Konstam, et al. (US 2019/0303808) (“Konstam”).
Regarding claim 19, Bergdale discloses that the token and the security component provides the certificate and access to the event (Bergdale ¶¶ 51-52).
Bergdale in view of Shore does not specifically disclose that rotation of the certificate is performed wholly locally on the mobile computing device.
SafeTix discloses that rotation of the certificate is performed wholly locally on the mobile computing device (SafeTix p. 1, paragraph starting “Built on the Present platform . . .”; p. 2 paragraph starting “Later this year, fans . . .”).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify the method of Bergdale in view of Shore to include rotation of the certificate being performed wholly locally on the mobile computing device, as disclosed in SafeTix, in order to protect against tickets being sold multiple times by unscrupulous resellers (SafeTix, p. 1, “These enhancements protect against tickets being screenshotted or photocopied and sold multiple times by unscrupulous resellers.”).
Bergdale in view of Shore, SafeTix, and Cocanougher does not specifically disclose that access is provided without network connectivity.
Konstam discloses providing access to an event without network connectivity (Konstam ¶¶ 19, 71-73).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify the method of Bergdale in view of Shore, SafeTix and Cocanougher to include providing access to an event without network connectivity, as disclosed in Konstam, in order to allow for authenticating a ticket holder at the entrance of an event, regardless of where the event is located (Konstam ¶ 19).
Regarding claim 20, Bergdale discloses transferring the token from the mobile computing device to an additional mobile computing device associated with a user that is different from the token owner (Bergdale ¶¶ 47, 51, 58, 62).
Bergdale in view of Shore, SafeTix and Cocanougher does not specifically disclose that transferring the token does not require the secondary token server or the primary token server.
Konstam discloses transferring the token does not require the secondary token server or the primary token server (Konstam ¶ 39).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify the method of Bergdale in view of Shore, SafeTix, and Cocanougher to include transferring the token does not require the secondary token server or the primary token server, as disclosed in Konstam, in order to allow for authenticating a ticket holder at the entrance of an event, regardless of where the event is located (Konstam ¶ 19).
Statement Regarding Prior Art for Claims 1-14
As described above, Bergdale discloses a server configured to receive a credential corresponding a credential owner from a mobile computing device (Bergdale ¶¶ 45, 51-52);
validate that the credential owner has ownership of a token corresponding to an event (Bergdale ¶¶ 45, 52);
generate an identifier that provides access to a certificate corresponding to the token and corresponding to a security component (Bergdale ¶¶ 45-46, 51-52, 70);
transmit the identifier to the mobile computing device corresponding to the credential owner (Bergdale ¶¶ 45, 51-52).
SafeTix further discloses a security component that comprises executable software instructions that, when executed by a processor of the mobile computing device, cause the mobile computing device to rotate a certificate at a predetermined time interval, including rotating the certificate locally on the mobile computing device (SafeTix p. 1, paragraph starting “Built on the Present platform . . .”; p. 2 paragraph starting “Later this year, fans . . .”).
However, the prior art does not disclose the combination of performing the claimed functions on the primary and secondary servers, while also executing the security component as claimed on the user’s device, which involves executing a set of executable software instructions that are delivered by the secondary token server to the mobile computing device via a content referenced by the network address a rotation of the certificate at a predetermined time interval, wherein the certificate is rotated locally by the security component on the mobile computing device without any network connectivity after provisioning of the mobile computing device.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Du, et al. (US 2014/0100896) (“Du”) discloses validating tickets by scanning them and transferring tickets to another user, as well as converting physical tickets to electronic tickets (See, Du Abstract; Figures 5-6).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Mohammad A. Nilforoush whose telephone number is (571)270-5298. The examiner can normally be reached Monday-Friday 12pm-7pm.
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, John W. Hayes can be reached at 571-272-6708. 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.
/Mohammad A. Nilforoush/Primary Examiner, Art Unit 3697
Prosecution Insights