DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, 18/847,108, filed 09/13/2024 is a National Stage entry of PCT/US2023/017067, International Filing Date of 03/31/2023, which in turn claims priority from U.S. Provisional Application 63/342,839, filed 05/17/2022.
The effective filing date is after the AIA date of March 16, 2013, and so the application is being examined under the “first inventor to file” provisions of the AIA .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Status of the Application
This Second Non-Final Office Action is in response to Applicant’s communication of 12/29/2025.
This action newly examines the claims filed in the Amendment to the claims under PCT Article 19 received by the International Bureau on 10 Oct. 2023, instead of the originally filed claims.
Claims 1-20 are pending, of which claims 1, 15, and 16 are independent.
All pending claims have been examined on the merits.
Information Disclosure Statement
The Information Disclosure Statement (IDS) submitted on 9/13/2024 was previously considered.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. §101 because the claimed invention is directed to non-statutory subject matter. The claimed invention is directed to an abstract idea, without “significantly more”.
Based on the flowchart in MPEP § 2106, Step 1 of the Alice/Mayo analysis is: “Is the claim to a process, machine, manufacture or composition of matter?”
In regards to Step 1 of the Alice/Mayo analysis, independent claims 1 and 16 are method claims, and claim 15 is an apparatus claim.
For the sake of compact prosecution, we continue with the Alice/Mayo “abstract idea” analysis.
Step 2A, prong 1 of the Alice/Mayo analysis is: “Does the claim recite a law of nature, a natural phenomenon (product of nature), or an abstract idea?”
In regards to Step 2A, prongs 1 and 2 of the Alice/Mayo analysis, the abstract idea elements recited in independent claim 1, 15, and 16 are shown in italic font. (The “additional elements” and “extra solution steps” are shown in italic and underlined font):
In regards to claim 1,
1. A method comprising:
receiving, by a processing computer from an authorizing entity computer, an enrollment data packet including device information of a user and resource provider information;
generating, by the processing computer, a token request push data packet including user information and the device information;
transmitting, by the processing computer to a user device, the token request push data packet, wherein the user device thereafter transmits a request to initiate token provisioning to a resource provider computer associated with the resource provider information;
receiving, by the processing computer from the resource provider computer, a provisioning request generated based on the request to initiate the token provisioning; and
transmitting, by the processing computer to a token service computer, the provisioning request including the token request push data packet,
wherein, upon receiving the provisioning request, the token service computer determines token data using the device information and the user information from the token request push data packet, and provides the token data to the resource provider computer.
In regards to claim 15,
15. A processing computer comprising:
a processor; and
a computer-readable medium comprising code that, when executed by the processor, causes the processor to perform a method including:
receiving, from an authorizing entity computer, an enrollment data packet including device information of a user and resource provider information;
generating a token request push data packet including user information and the device information;
transmitting, to a user device, the token request push data packet, wherein the user device thereafter transmits a request to initiate token provisioning to a resource provider computer associated with the resource provider information;
receiving, from the resource provider computer, a provisioning request generated based on the request to initiate the token provisioning; and
transmitting, to a token service computer, the provisioning request including the token request push data packet,
wherein, upon receiving the provisioning request, the token service computer determines token data using the device information and the user information from the token request push data packet and provides the token data to the resource provider computer.
In regards to claim 16,
16. A method comprising:
transmitting, by a user device operated by a user to an authorizing entity computer, device information of the user and resource provider information of a resource provider, wherein the authorizing entity computer thereafter generates and transmits, to a processing computer, an enrollment data packet including the device information and the resource provider information;
receiving, by the user device, a token request push data packet including user information and the device information; and
in response to the receiving the token request push data packet, transmitting, by the user device a request to initiate token provisioning to a resource provider computer associated with the resource provider information,
wherein the resource provider computer thereafter transmits, to the processing computer, a provisioning request generated based on the request to initiate the token provisioning,
wherein the processing computer transmits, to a token service computer, the provisioning request including the token request push data packet, and
wherein, upon receiving the provisioning request, the token service computer generates token data using the device information and the user information from the token request push data packet and provides the token data to the resource provider computer.
More specifically, claims 1-20 recite an abstract idea: “Commercial or Legal Interactions (Including Agreements in the form of Contracts; Legal Obligations; Advertising, Marketing, or Sales Activities or Behaviors; Business Relations)”, as discussed in MPEP §2106(a)(2) Parts (I) and (II), and in the 2019 Revised Patent Subject Matter Eligibility Guidance.
In regards to claims 1 and 15, the “Commercial or Legal Interactions” elements include:
“generating … a token request push data packet including user information and the device information”.
“wherein, upon receiving the provisioning request, the token service computer determines token data using the device information and the user information from the token request push data packet”.
In regards to claim 16, the “Commercial or Legal Interactions” elements include:
“wherein the authorizing entity computer thereafter generates … an enrollment data packet including the device information and the resource provider information”.
“wherein … the token service computer generates token data using the device information and the user information from the token request push data packet”.
In regards to claims 1 and 15, the “additional elements” include: “a processing computer”, “an authorizing entity computer”, “a user device”, “a resource provider computer”, and “a token service computer”.
In regards to claim 16, the “additional elements” include: “a processing computer”, “an authorizing entity computer”, “a user device operated by a user”, “a resource provider computer”, and “a token service computer”.
Moreover, in regards to claims 1 and 15, the “additional extra-solution elements” include: “receiving … an enrollment data packet including device information of a user and resource provider information”, “transmitting … the token request push data packet”, “transmits a request to initiate token provisioning”, “receiving … a provisioning request generated based on the request to initiate the token provisioning”, “transmitting … the provisioning request including the token request push data packet”, and “provides the token data to the resource provider computer”.
Moreover, in regards to claim 16, the “additional extra-solution elements” include: “transmitting … device information of the user and resource provider information of a resource provider”, “transmits … an enrollment data packet including the device information and the resource provider information”, “receiving … a token request push data packet including user information and the device information”, “receiving the token request push data packet”, “transmitting … a request to initiate token provisioning to a resource provider computer associated with the resource provider information”, “transmits … a provisioning request generated based on the request to initiate the token provisioning”, “transmits … the provisioning request including the token request push data packet”, “receiving the provisioning request”, “receiving the provisioning request”, and “provid[ing] the token data to the resource provider computer”.
Step 2A, prong 2 of the Alice/Mayo analysis is “Does the claim recite additional elements that integrate elements that integrate the judicial exception into a practical application?”
In regards to Step 2A, prong 2 of the Alice/Mayo analysis, this abstract idea is not integrated into a practical application, because:
The claim is directed to an abstract idea with additional generic computer elements. The generically recited computer elements (In claims 1 and 15: “a processor”, “a computer-readable medium comprising code”, “an authorizing entity computer”, “a user device”, “a resource provider computer”, and “a token service computer”; In claim 16: “a processing computer”, “an authorizing entity computer”, “a user device operated by a user”, “a resource provider computer”, and “a token service computer”) do not add a meaningful limitation to the abstract idea, because they amount to simply implementing the abstract idea on a computer. The claim amounts to adding the words "apply it" (or an equivalent) with the abstract idea, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea.
The extra-solution activities in claims 1 and 15: “receiving … an enrollment data packet including device information of a user and resource provider information”, “transmitting … the token request push data packet”, “transmits a request to initiate token provisioning”, “receiving … a provisioning request generated based on the request to initiate the token provisioning”, “transmitting … the provisioning request including the token request push data packet”, “receiving the provisioning request”, and “provid[ing] the token data to the resource provider computer”.
The extra-solution activities in claim 16: “transmitting … device information of the user and resource provider information of a resource provider”, “transmits … an enrollment data packet including the device information and the resource provider information”, “receiving … a token request push data packet including user information and the device information”, “receiving the token request push data packet”, “transmitting … a request to initiate token provisioning to a resource provider computer associated with the resource provider information”, “transmits … a provisioning request generated based on the request to initiate the token provisioning”, “transmits … the provisioning request including the token request push data packet”, “receiving the provisioning request”, “receiving the provisioning request”, and “provid[ing] the token data to the resource provider computer”)
These extra-solution activities in claims 1, 15, and 16 do not add a meaningful limitation to the method, as they are insignificant extra-solution activity;
The combination of the abstract idea with the additional elements (generically recited computer elements), and/or with the extra-solution activities, does not integrate the abstract idea into a practical application.
Step 2B of the Alice/Mayo analysis is: “Does the claim recite additional elements that amount to significantly more than the judicial exception?”
In regards to Step 2B of the Alice/Mayo analysis, the claims do not include additional elements that are sufficient to amount to significantly more than the abstract idea, because:
When considering the elements "alone and in combination", they do not add significantly more (also known as an "inventive concept") to the exception, because they amount to simply implementing the abstract idea on a computer. Instead, they merely add the words "apply it" (or an equivalent) with the abstract idea, or mere instructions to implement an abstract idea on a computer, or merely use a computer as a tool to perform an abstract idea.
In regards to the extra solution activities (“transmitting”, “receiving”, and “providing”), these are recognized as such by the court decisions listed in MPEP § 2106.05(d).
More specifically, in regards to the “transmitting”, “receiving”, and “providing” steps, see the court cases OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network) and (presenting offers and gathering statistics), OIP Techs., 788 F.3d at 1362-63, 115 USPQ2d at 1092-93; buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network).
Moreover, in regards to “apply it”, according to MPEP § 2106.05(f)(2):
Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application or provide significantly more. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262, 120 USPQ2d 1201, 1207 (Fed. Cir. 2016) (cellular telephone); TLI Communications LLC v. AV Auto, LLC, 823 F.3d 607, 613, 118 USPQ2d 1744, 1748 (Fed. Cir. 2016) (computer server and telephone unit). Similarly, "claiming the improved speed or efficiency inherent with applying the abstract idea on a computer" does not integrate a judicial exception into a practical application or provide an inventive concept. Intellectual Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363, 1367, 115 USPQ2d 1636, 1639 (Fed. Cir. 2015).
In contrast, a claim that purports to improve computer capabilities or to improve an existing technology may integrate a judicial exception into a practical application or provide significantly more. McRO, Inc. v. Bandai Namco Games Am. Inc., 837 F.3d 1299, 1314-15, 120 USPQ2d 1091, 1101-02 (Fed. Cir. 2016); Enfish, LLC v. Microsoft Corp., 822 F.3d 1327, 1335-36, 118 USPQ2d 1684, 1688-89 (Fed. Cir. 2016). See MPEP §§ 2106.04(d)(1) and 2106.05(a) for a discussion of improvements to the functioning of a computer or to another technology or technical field.
The Examiner holds that the independent claims “use a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data)” or “simply add a general purpose computer or computer components after the fact to an abstract idea”.
Independent claim 1 is rejected on the same grounds as independent claim 15.
All dependent claims are also rejected, because they merely further define the abstract idea.
Claim Rejections - 35 USC § 103
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over US-11,683,157-B2 to Yin et al. (“Yin”. Eff. Filed on Mar. 3, 2017. Published on Aug. 19, 2021) in view of US 2020/0311239 A1 to Sardari et al. (“Sardari”. Eff. Filed on Sept. 14, 2017. Published on Oct. 1, 2020)
In regards to claim 1,
1. A method comprising:
receiving, by a processing computer from an authorizing entity computer, an enrollment data packet including device information of a user and resource provider information;
(See Yin, claim 1: “A device, comprising: one or more processors configured to: receive, from a network device, information that identifies a user device and comprises information parsed from a packet received by the network device from the user device, based on the user device being authenticated by the network device; receive, from the user device, a session identifier and a request for a first token, where the session identifier is generated by a server device and provided to the user device; and where the request for the first token includes an application identifier identified by the network device based on the information parsed from the packet received by the network device from the user device; generate the first token based on the session identifier and the information that identifies the user device; and provide, to the user device, information that identifies the first token, the user device to provide, to the server device, the information that identifies the first token, the server device to compare the first token and a second token generated by the server device based on information associated with the user device and the session identifier, and the server device, based on comparing the first token and the second token, to enable the user device to receive content associated with the server device.”)
generating, by the processing computer, a token request push data packet including user information and the device information;
(See Yin, claim 1: “A device, comprising: one or more processors configured to: receive, from a network device, information that identifies a user device and comprises information parsed from a packet received by the network device from the user device, based on the user device being authenticated by the network device; receive, from the user device, a session identifier and a request for a first token, where the session identifier is generated by a server device and provided to the user device; and where the request for the first token includes an application identifier identified by the network device based on the information parsed from the packet received by the network device from the user device; generate the first token based on the session identifier and the information that identifies the user device; and provide, to the user device, information that identifies the first token, the user device to provide, to the server device, the information that identifies the first token, the server device to compare the first token and a second token generated by the server device based on information associated with the user device and the session identifier, and the server device, based on comparing the first token and the second token, to enable the user device to receive content associated with the server device.”)
transmitting, by the processing computer to a user device, the token request push data packet, wherein the user device thereafter transmits a request to initiate token provisioning to a resource provider computer associated with the resource provider information;
(See Yin, claim 1: “A device, comprising: one or more processors configured to: receive, from a network device, information that identifies a user device and comprises information parsed from a packet received by the network device from the user device, based on the user device being authenticated by the network device; receive, from the user device, a session identifier and a request for a first token, where the session identifier is generated by a server device and provided to the user device; and where the request for the first token includes an application identifier identified by the network device based on the information parsed from the packet received by the network device from the user device; generate the first token based on the session identifier and the information that identifies the user device; and provide, to the user device, information that identifies the first token, the user device to provide, to the server device, the information that identifies the first token, the server device to compare the first token and a second token generated by the server device based on information associated with the user device and the session identifier, and the server device, based on comparing the first token and the second token, to enable the user device to receive content associated with the server device.”)
However, under a conservative interpretation of Yin, even though the cited claim 1 of Yin teaches “and the server device, based on comparing the first token and the second token, to enable the user device to receive content associated with the server device”, it could be argued that Yin does not explicitly teach the italicized portions below, which are taught by Sardari:
receiving, by the processing computer from the resource provider computer, a provisioning request generated based on the request to initiate the token provisioning; and
transmitting, by the processing computer to a token service computer, the provisioning request including the token request push data packet, wherein, upon receiving the provisioning request, the token service computer determines token data using the device information and the user information from the token request push data packet, and provides the token data to the resource provider computer.
(See Sardari , para. [0005]: “Another embodiment discloses a system comprising: one or more hardware processors, the one or more hardware processors configured to execute specific computer-executable instructions to at least: receive a request to initiate a pairing between a periphery computing device with a user account associated with a video game application, the user account previously authenticated on the user computing device; output a first audio output from an audio output system of the user computing system in response to the request to pair the periphery computing device with the user account, the first audio output configured to request identification data from the periphery device; receive a second audio output from the periphery computing device, responsive to the first audio output, the second audio output comprising identification data identifying the periphery computing device; transmit, over a network, an authentication request data packet to a remote authentication manager, for a pairing between the periphery computing device and a user account; receive, over the network, an authentication response data packet from the remote authentication manager, the authentication response data packet comprising an authentication token for the periphery computing device; output a third audio output from the audio output system of the user computing system, the third audio output comprising the authentication token and authentication access information, wherein the periphery computing device is configured to communication with the remote authentication server using the authentication access information and pair the periphery computing device using the authentication token; and receive, over the network, a confirmation data packet from the remote authentication manager, the confirmation data packet indicating pairing of the periphery computing device and the user account is complete.”)
It would have been obvious to a person having ordinary skill in the art (PHOSITA), before the effective filing date of the claimed invention, to include in the method for “Network-based device registration for content distribution platforms”, as taught by Yin above, with “Audio-based device authentication system”, as further taught by Sardari above, because Sardari teaches that the communicated digital information (tokens) are used for authentication.
In regards to claim 2,
2. The method of claim 1, wherein the authorizing entity computer authenticates the user and generates the enrollment data packet based on the user being authenticated.
(See Sardari , para. [0005]: “Another embodiment discloses a system comprising: one or more hardware processors, the one or more hardware processors configured to execute specific computer-executable instructions to at least: receive a request to initiate a pairing between a periphery computing device with a user account associated with a video game application, the user account previously authenticated on the user computing device; output a first audio output from an audio output system of the user computing system in response to the request to pair the periphery computing device with the user account, the first audio output configured to request identification data from the periphery device; receive a second audio output from the periphery computing device, responsive to the first audio output, the second audio output comprising identification data identifying the periphery computing device; transmit, over a network, an authentication request data packet to a remote authentication manager, for a pairing between the periphery computing device and a user account; receive, over the network, an authentication response data packet from the remote authentication manager, the authentication response data packet comprising an authentication token for the periphery computing device; output a third audio output from the audio output system of the user computing system, the third audio output comprising the authentication token and authentication access information, wherein the periphery computing device is configured to communication with the remote authentication server using the authentication access information and pair the periphery computing device using the authentication token; and receive, over the network, a confirmation data packet from the remote authentication manager, the confirmation data packet indicating pairing of the periphery computing device and the user account is complete.”)
In regards to claim 3,
3. The method of claim 2, wherein the authorizing entity computer authenticates the user by allowing the user to log in to a user account and evaluating login credentials of the user.
(See Yin, col.2, lines 10-18: “In some cases, a user might be required to manually configure each client device. For example, a user might, using a peripheral device, interact with a client device to enter an activation code and/or login credentials. In other cases, the client device can provide an activation code for display, and the user, using a different device (e.g., in cases where the client device does include peripheral device connectivity), can access a webpage and enter the activation code.”)
In regards to claim 4,
4. The method of claim 1, wherein receiving the token request push data packet by the user device invokes a resource provider application on the user device.
(See Yin, col.2, line 53 to col.3, line 2: “FIGS. 1A-1O are diagrams of an overview of an example implementation 100 described herein. As shown in FIG. 1A, example implementation 100 can include a provisioning server and an authentication server. In some implementations, the provisioning server can provide, to the authentication server, information associated with an application that is to be used in association with a content provisioning service. For example, a set of user devices can execute client applications (e.g., content provisioning applications) that enable the user devices to receive content (e.g., video content, advertisement content, image content, etc.) from a set of content servers, and provide the content for display. The authentication server can enable a registration service whereby the authentication server can provide, to the set of content servers, authentication and/or registration information which enables the set of content servers to authenticate and/or register a set of user devices to receive content.”)
In regards to claim 5,
5. The method of claim 4,
wherein the resource provider computer authenticates the user via the resource provider application, and
based on authenticating the user, transmits, to the processing computer, the provisioning request that notifies the processing computer that the resource provider computer authorized an enrollment of the user.
(See Yin, col.8, lines 7-20: “AAA 245 includes one or more devices, such as one or more server devices, that perform authentication, authorization, and/or accounting operations for communication sessions associated with user device 205. For example, AAA 245 can perform authentication operations for user device 205 and/or a user of user device 205 (e.g., using one or more credentials), can control access, by user device 205, to a service and/or an application (e.g., based on one or more restrictions, such as time-of-day restrictions, location restrictions, single or multiple access restrictions, read/write restrictions, etc.), can track resources consumed by user device 205 (e.g., a quantity of voice minutes consumed, a quantity of data consumed, etc.), and/or can perform similar operations.”)
In regards to claim 6,
6. The method of claim 1, wherein:
the resource provider information identifies a resource provider, and
the method further comprises:
in response to receiving the enrollment data packet, determining, by the processing computer, whether the resource provider is an on behalf of (OBO) resource provider that is not in communication with the token service computer or a not-OBO resource provider that is in communication with the token service computer.
(See Yin, col. 11, lines 36-43: “As indicated above, FIG. 4 is provided merely as an example. Other examples are possible and can differ from what was described with regard to FIG. 4 . While a particular series of operations and/or data flows have been described above with regard to FIG. 4 , the order of the operations and/or data flows can be modified in other implementations. Further, non-dependent operations can be performed in parallel.”)
(See Yin, col. 11, lines 44-53: “In this way, authentication server 230, enforcement server 235, and/or content server 255 can be provisioned, for a registration service, based on information provided by provisioning server 250 (e.g., which might have received the information from a client device). Additionally, in this way, a third party associated with the content provisioning service can register for the registration service, which enables content server 255 to receive, from authentication server 230, information that identifies a network-based authentication of user device 205, as described elsewhere herein.”)
In regards to claim 7,
7. The method of claim 6,
wherein the generating the token request push data packet further comprises:
in response to the determining the resource provider being the OBO resource provider, generating the token request push data packet to include the user information and the device information,
wherein the device information comprises a primary account number; and
(See Yin, col. 10, lines 31-39: “In some implementations, provisioning server 250 can generate an account for a registration service to be used in association with the application. For example, as described elsewhere herein, the registration service can enable the automatic registration and authentication of user devices 205 that might execute the application. Additionally, or alternatively, provisioning server 250 can generate an account identifier for the account, and/or can generate an application identifier.”)
in response to the determining the resource provider being the not- OBO resource provider, generating the token request push data packet to include the user information and the device information,
wherein the device information comprises a reference identifier corresponding to a primary account number.
(See Yin, col. 10, lines 53-57: “In some implementations, provisioning server 250 can store, in a data structure (e.g., a device provisioning table), the information associated with the application (e.g., information that identifies the account identifier, the application identifier, the application certificate, the set of content servers 255, and/or the set of user devices 205).”)
In regards to claim 8,
8. The method of claim 1, further comprising:
prior to the transmitting the provisioning request, appending, by the processing computer, the token request push data packet to the provisioning request received from the resource provider computer, to generate an updated provisioning request,
wherein the provisioning request that is sent to the token service computer is the updated provisioning request.
(See Yin, col.13, lines 36-44: “As further shown in FIG. 6A, and by reference number 608, user device 205 can provide, to authentication server 230, a request for a first token. In some implementations, the request for the first token can include information that identifies the application identifier, and the encrypted session identifier and four-tuple information. In some implementations, and as described elsewhere herein, the first token can include information that can be used by content server 255 to determine whether user device 205 has been authenticated by authentication server 230.”)
In regards to claim 9,
9. The method of claim 1,
wherein the token data comprises at least one from among a token and a token reference identifier.
(See Yin, col.5, lines 3-12: “As shown in FIG. 1J, and by reference number 134, the authentication server can generate a token and can encrypt the token and the session identifier using the application public key. For example, the authentication server can generate the token using a hashing algorithm, the application identifier, the session identifier, the MDN of the user device, and the four-tuple information. As further shown in FIG. 1J, and by reference number 136, the authentication server can provide, to the user device, the encrypted token and session identifier.”)
(See Yin, col.5, lines 13-21: “As shown in FIG. 1K, and by reference number 138, the user device can provide, to the content server, a registration request including information that identifies the application identifier, the MDN of the user device, a client certificate, and the encrypted token and session identifier. As further shown in FIG. 1K, and by reference number 140, the content server can identify the application private key based on the application identifier, and decrypt the encrypted token and session identifier.”)
In regards to claim 10,
10. The method of claim 9,
wherein the token data comprises the token that is 16 digits long.
Official Notice is given that the 16 digit character length of the claimed token is an merely obvious variation of the possible token length, and is a design choice.
In regards to claim 11,
11. The method of claim 9,
wherein the at least one from among the token and the token reference identifier is stored by the resource provider computer to be used in a future interaction with respect to the user.
Official Notice is given that the storage of data for future use is old, well known, and obvious.
In regards to claim 12,
12. The method of claim 1, wherein:
the token service computer provides the token data to the resource provider computer via a service provider computer, and
prior to the providing the token data to the service provider computer, the token service computer generates a token creation notification including token information and provides the token creation notification to the service provider computer.
(See Yin, col. 5, lines 3-12: “As shown in FIG. 1J, and by reference number 134, the authentication server can generate a token and can encrypt the token and the session identifier using the application public key. For example, the authentication server can generate the token using a hashing algorithm, the application identifier, the session identifier, the MDN of the user device, and the four-tuple information. As further shown in FIG. 1J, and by reference number 136, the authentication server can provide, to the user device, the encrypted token and session identifier.”)
(See Yin, col. 5, lines 13-21: “As shown in FIG. 1K, and by reference number 138, the user device can provide, to the content server, a registration request including information that identifies the application identifier, the MDN of the user device, a client certificate, and the encrypted token and session identifier. As further shown in FIG. 1K, and by reference number 140, the content server can identify the application private key based on the application identifier, and decrypt the encrypted token and session identifier.”)
In regards to claim 13,
13. The method of claim 12,
wherein the token information includes a provisioning request identifier identifying the provisioning request and a token reference identifier identifying a token.
(See Yin, col.5, lines 3-12: “As shown in FIG. 1J, and by reference number 134, the authentication server can generate a token and can encrypt the token and the session identifier using the application public key. For example, the authentication server can generate the token using a hashing algorithm, the application identifier, the session identifier, the MDN of the user device, and the four-tuple information. As further shown in FIG. 1J, and by reference number 136, the authentication server can provide, to the user device, the encrypted token and session identifier.”)
In regards to claim 14,
14. The method of claim 1,
wherein a resource provider associated with the resource provider information is selected by the user before the enrollment data packet is received by the processing computer.
(See Yin, col.4, lines 34-49: “As shown in FIG. 1F, and by reference number 120, the user device can provide, to the content server, an activation request including the application identifier. As further shown in FIG. 1F, and by reference number 122, the content server can generate a session identifier and encrypt the session identifier and the four-tuple information using the service public key. Additionally, the content server can store, in a data structure (e.g., an activation table), information that identifies the application identifier, the four-tuple information, the session identifier, and an expiration time associated with the session identifier (e.g., a time frame for which the session identifier is valid). As further shown in FIG. 1F, the content server can provide, to the user device, an activation response that includes information that identifies the application identifier and the encrypted session identifier and four-tuple information.”)
In regards to claim 15, it is rejected on the same grounds as claim 1.
In regards to claim 16,
16. A method comprising:
transmitting, by a user device operated by a user to an authorizing entity computer, device information of the user and resource provider information of a resource provider,
wherein the authorizing entity computer thereafter generates and transmits, to a processing computer, an enrollment data packet including the device information and the resource provider information;
(See Yin, claim 1: “A device, comprising: one or more processors configured to: receive, from a network device, information that identifies a user device and comprises information parsed from a packet received by the network device from the user device, based on the user device being authenticated by the network device; receive, from the user device, a session identifier and a request for a first token, where the session identifier is generated by a server device and provided to the user device; and where the request for the first token includes an application identifier identified by the network device based on the information parsed from the packet received by the network device from the user device; generate the first token based on the session identifier and the information that identifies the user device; and provide, to the user device, information that identifies the first token, the user device to provide, to the server device, the information that identifies the first token, the server device to compare the first token and a second token generated by the server device based on information associated with the user device and the session identifier, and the server device, based on comparing the first token and the second token, to enable the user device to receive content associated with the server device.”)
receiving, by the user device, a token request push data packet including user information and the device information; and
(See Yin, claim 1: “A device, comprising: one or more processors configured to: receive, from a network device, information that identifies a user device and comprises information parsed from a packet received by the network device from the user device, based on the user device being authenticated by the network device; receive, from the user device, a session identifier and a request for a first token, where the session identifier is generated by a server device and provided to the user device; and where the request for the first token includes an application identifier identified by the network device based on the information parsed from the packet received by the network device from the user device; generate the first token based on the session identifier and the information that identifies the user device; and provide, to the user device, information that identifies the first token, the user device to provide, to the server device, the information that identifies the first token, the server device to compare the first token and a second token generated by the server device based on information associated with the user device and the session identifier, and the server device, based on comparing the first token and the second token, to enable the user device to receive content associated with the server device.”)
in response to the receiving the token request push data packet, transmitting, by the user device a request to initiate token provisioning to a resource provider computer associated with the resource provider information,
wherein the resource provider computer thereafter transmits, to the processing computer, a provisioning request generated based on the request to initiate the token provisioning,
(See Yin, claim 1: “A device, comprising: one or more processors configured to: receive, from a network device, information that identifies a user device and comprises information parsed from a packet received by the network device from the user device, based on the user device being authenticated by the network device; receive, from the user device, a session identifier and a request for a first token, where the session identifier is generated by a server device and provided to the user device; and where the request for the first token includes an application identifier identified by the network device based on the information parsed from the packet received by the network device from the user device; generate the first token based on the session identifier and the information that identifies the user device; and provide, to the user device, information that identifies the first token, the user device to provide, to the server device, the information that identifies the first token, the server device to compare the first token and a second token generated by the server device based on information associated with the user device and the session identifier, and the server device, based on comparing the first token and the second token, to enable the user device to receive content associated with the server device.”)
However, under a conservative interpretation of Yin, even though the cited claim 1 of Yin teaches “and the server device, based on comparing the first token and the second token, to enable the user device to receive content associated with the server device”, it could be argued that Yin does not explicitly teach the italicized portions below, which are taught by Sardari:
wherein the processing computer transmits, to a token service computer, the provisioning request including the token request push data packet, and
wherein, upon receiving the provisioning request, the token service computer generates token data using the device information and the user information from the token request push data packet and provides the token data to the resource provider computer.
(See Sardari , para. [0005]: “Another embodiment discloses a system comprising: one or more hardware processors, the one or more hardware processors configured to execute specific computer-executable instructions to at least: receive a request to initiate a pairing between a periphery computing device with a user account associated with a video game application, the user account previously authenticated on the user computing device; output a first audio output from an audio output system of the user computing system in response to the request to pair the periphery computing device with the user account, the first audio output configured to request identification data from the periphery device; receive a second audio output from the periphery computing device, responsive to the first audio output, the second audio output comprising identification data identifying the periphery computing device; transmit, over a network, an authentication request data packet to a remote authentication manager, for a pairing between the periphery computing device and a user account; receive, over the network, an authentication response data packet from the remote authentication manager, the authentication response data packet comprising an authentication token for the periphery computing device; output a third audio output from the audio output system of the user computing system, the third audio output comprising the authentication token and authentication access information, wherein the periphery computing device is configured to communication with the remote authentication server using the authentication access information and pair the periphery computing device using the authentication token; and receive, over the network, a confirmation data packet from the remote authentication manager, the confirmation data packet indicating pairing of the periphery computing device and the user account is complete.”)
It would have been obvious to a person having ordinary skill in the art (PHOSITA), before the effective filing date of the claimed invention, to include in the method for “Network-based device registration for content distribution platforms”, as taught by Yin above, with “Audio-based device authentication system”, as further taught by Sardari above, because Sardari teaches that the communicated digital information (tokens) are used for authentication.
In regards to claim 17,
17. The method of claim 16, wherein the receiving the token request push data packet causes the user device to invoke a resource provider application associated with the resource provider computer on the user device.
(See Yin, col.4, lines 34-49: “As shown in FIG. 1F, and by reference number 120, the user device can provide, to the content server, an activation request including the application identifier. As further shown in FIG. 1F, and by reference number 122, the content server can generate a session identifier and encrypt the session identifier and the four-tuple information using the service public key. Additionally, the content server can store, in a data structure (e.g., an activation table), information that identifies the application identifier, the four-tuple information, the session identifier, and an expiration time associated with the session identifier (e.g., a time frame for which the session identifier is valid). As further shown in FIG. 1F, the content server can provide, to the user device, an activation response that includes information that identifies the application identifier and the encrypted session identifier and four-tuple information.”)
In regards to claim 18,
18. The method of claim 17,
wherein the resource provider computer authenticates the user via the resource provider application and based on the authentication of the user, transmits, to the processing computer, the provisioning request,
wherein the provisioning request notifies the processing computer that the resource provider computer authorized an enrollment of the user.
(See Yin, col.11, line 59 to col.12, line 3: “As shown in FIG. 5 , and by reference number 505, user device 205 and PGW 225 can establish an IP session (e.g., based on an attach procedure). For example, HSS 240 and/or AAA 245 can perform authentication, registration, session initiation, and/or authorization procedures based on user device 205 accessing a RAN (e.g., the LTE network via base station 210). In some implementations, PGW 225 can establish an IP session for user device 205 based on HSS 240 and/or AAA 245 authenticating user device 205. For example, an IP session can include information identifying a connection of user device 205 to the RAN and/or external packet networks.”)
In regards to claim 19,
19. The method of claim 16,
wherein the token data comprises a token, and
wherein the token is stored by the resource provider computer to be used in a future interaction with respect to the user.
Official Notice is given that the storage of data for future use is well known and obvious.
In regards to claim 20,
20. The method of claim 16,
wherein the token data comprises at least one from among a token reference identifier and a token corresponding to a primary account number of the user.
(See Yin, col.5, lines 3-12: “As shown in FIG. 1J, and by reference number 134, the authentication server can generate a token and can encrypt the token and the session identifier using the application public key. For example, the authentication server can generate the token using a hashing algorithm, the application identifier, the session identifier, the MDN of the user device, and the four-tuple information. As further shown in FIG. 1J, and by reference number 136, the authentication server can provide, to the user device, the encrypted token and session identifier.”)
Conclusion
Applicants are invited to contact the Office to schedule an in-person interview to discuss and resolve the issues set forth in this Office Action. Although an interview is not required, the Office believes that an interview can be of use to resolve any issues related to a patent application in an efficient and prompt manner.
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.
Any inquiry concerning this communication or earlier communications should be directed to Examiner Ayal Sharon, whose telephone number is (571) 272-5614, and fax number is (571) 273-1794. The Examiner can normally be reached from Monday to Friday between 9 AM and 6 PM. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, SPE Christine Behncke can be reached at (571) 272-8103 or at christine.behncke@uspto.gov. The fax 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.
Sincerely,
/Ayal I. Sharon/
Examiner, Art Unit 3695
March 29, 2026
Prosecution Insights