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 .
DETAILED ACTION
This communication is a Non-Final Office Action rejection on the merits.
Claim 1, was originally filed, and cancelled.
Claims 2-21, are newly added, therefore
Claims 2-21 are currently pending and have been addressed below.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 2-21 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-5, 7-8, 10, 15, 17, 20 of U.S. Patent No. 12,211,049 (Jie He), respectively. The claims at issue are not patentably distinct from each other as shown in bold in the table below.
Patent. No 12/211,049
Present Application:
18/976,889
Examiner’s Notes
1, 8 and 15. A system for determining the health of social tokens, the system comprising:
a processing unit comprising one or more processors; and memory coupled with and readable by the processing unit and storing therein a set of instructions which, when executed by the processing unit, causes the system to perform operations including:
receiving data associated with a sender including a social token used by the sender, wherein the data associated with the sender is used by a data assessment system to generate an account associated with the sender;
receiving from a plurality of entities, account data associated with a plurality of accounts maintained at the entities, wherein the account data includes at least data pertaining to use of the social token in transactions conducted using each of the plurality of accounts;
generating a health score for the social token used by the sender, wherein:
the health score is indicative of a level of risk for transactions that use the social token used by the sender; and
generating the health score for the social token associated with the sender comprises analyzing the data pertaining to use of the social token used by the sender in transactions conducted using each of the plurality of accounts, wherein the health score for the social token comprises one or both of a score that is indicative of a level of risk for use of the social token by the sender as a payee in a transaction and a score that is indicative of a level of risk for use of the social token by the sender as a payer in a transaction;
receiving, from the sender at an application displayed on a graphical user interface (GUI) of a network device associated with the sender, data associated with a transaction initiated by the sender using the account associated with the sender, wherein the data associated with the transaction initiated by the sender includes at least a social token used by a receiver of the transaction;
generating a health score for the social token used by the receiver, wherein generating the health score for the social token used by the receiver includes analyzing data associated with the receiver, data pertaining to use of the social token used by the receiver in one or more prior transactions, and account data received from the plurality of entities;
determining a health score for the transaction using the health score for the social token used by the sender and the health score for the social token used by the receiver;
determining that the transaction should be rejected based on the health score for the transaction; and
based on determining that the transaction should be rejected and at least a portion of the received account data associated with the plurality of accounts maintained at the entities, locking the application at the network device associated with the sender.
From part of claims 1, 8 and 15 “…wherein the data associated with the transaction initiated by the sender includes at least a social token used by a receiver of the transaction;
generating a health score for the social token used by the receiver…”
From part of claims 1, 8 and 15
“…wherein generating the health score for the social token used by the receiver includes analyzing data associated with the receiver, data pertaining to use of the social token used by the receiver in one or more prior transactions…”
From part of claims 1, 8 and 15
“…wherein generating the health score for the social token used by the receiver includes analyzing data associated with the receiver, data pertaining to use of the social token used by the receiver in one or more prior transactions and account data received from the plurality of entities”
7. wherein the operations further include using the generated health score to generate a receiver health score for the social token associated with the sender for use in future events associated with the sender as receiver.
From part of claims 1, 8 and 15
“generating the health score for the social token associated with the sender comprises analyzing the data pertaining to use of the social token used by the sender in transactions conducted using each of the plurality of accounts, wherein the health score for the social token comprises one or both of a score that is indicative of a level of risk for use of the social token by the sender as a payee in a transaction and a score that is indicative of a level of risk for use of the social token by the sender as a payer in a transaction;”
5. wherein the operations further include: receiving updated data associated with a sender including the social token used by the sender; receiving, from the plurality of entities, updated account data associated with the plurality of accounts maintained at the entities, wherein the account data includes at least data pertaining to transactions conducted against each of the plurality of accounts; generating an updated health score for the social token used by the sender; and determining that the transaction should be approved based on the updated health score.
2. wherein locking the application at the network device associated with the sender includes locking the application at the network level to cause the application at the network device to be locked.
4. wherein the operations further include: after determining that the transaction should be declined, accessing a set of rules that indicate whether the declining of the transaction should be overridden; determining that the transaction should be approved based on the set of rules; and based on determining that the transaction should be approved, unlocking the application at the network device associated with the sender.
5. wherein the operations further include: receiving updated data associated with a sender including the social token used by the sender; receiving, from the plurality of entities, updated account data associated with the plurality of accounts maintained at the entities, wherein the account data includes at least data pertaining to transactions conducted against each of the plurality of accounts; generating an updated health score for the social token used by the sender; and determining that the transaction should be approved based on the updated health score.
3, 10 and 17. wherein determining that the event should be rejected based on the health score for the transaction includes comparing the health score to a threshold health score
20. wherein the social token is a QR code that was assigned to the receiver by the data assessment system to replace another social token submitted by the sender.
From part of claims 1, 8 and 15
“wherein the health score for the social token comprises one or both of a score that is indicative of a level of risk for use of the social token by the sender as a payee in a transaction and a score that is indicative of a level of risk for use of the social token by the sender as a payer in a transaction”
From part of claims 1, 8 and 15
“generating the health score for the social token associated with the sender comprises analyzing the data pertaining to use of the social token used by the sender in transactions conducted using each of the plurality of accounts, wherein the health score for the social token comprises one or both of a score that is indicative of a level of risk for use of the social token by the sender as a payee in a transaction and a score that is indicative of a level of risk for use of the social token by the sender as a payer in a transaction;”
2, 9 and 16. A system for determining the health of social tokens, the system comprising:
one or more processors; and a memory having instructions stored thereon that, when executed by the one or more processors, causes the system to:
receive data associated with a sender, wherein: the data associated with the sender is used by a data assessment system to generate an account associated with the sender; and the data associated with the sender comprises a social token used by the sender;
utilize the social token to retrieve account data associated with one or more accounts maintained at one or more entities, wherein the account data comprises data pertaining to use of the social token in transactions conducted using each of the one or more accounts;
analyze the data pertaining to use of the social token used by the sender in transactions conducted using each of the one or more accounts to
generate a health score for the social token used by the sender, wherein the health score for the social token used by the sender is indicative of a level of risk for use of the social token by the sender as a payer in a transaction;
receive, from the sender, data associated with a transaction initiated by the sender;
determine a health score for the transaction based at least in part the health score for the social token used by the sender and data associated with the transaction; and
determine whether the transaction should be approved or rejected based at least in part on the health score for the transaction.
3 and 18. wherein: the data associated with the transaction initiated by the sender comprises a social token used by a receiver of the transaction; and the instructions further cause the one or more processors to generate a health score for the social token used by the receiver.
4 and 11. wherein: the health score for the transaction is further determined based at least in part the health score for the social token used by the receiver.
5. wherein: generating the health score for the social token used by the receiver comprises analyzing data associated with the receiver, data pertaining to use of the social token used by the receiver in one or more prior transactions, and account data received from the one or more entities.
7. wherein: the account data comprises at least one of data associated with how long the social token used by the sender has been established, data associated with historical users of the social token used by the sender and information associated with each of those users, network behaviors associated with social token used by the sender over time, a velocity of payments associated with the social token used by the sender, a number of times the social token used by the sender has registered to a new financial institution over a certain time period, a number of times the social token used by the sender has registered to a new demand deposit account over a certain time period, or behavioral patterns associated with use of the social token used by the sender.
8. wherein: receive data indicating that the social token used by the sender has been involved in one or both of past possible fraud or past account abuse; and the health score for the social token used by the sender is determined based at least in part on the data indicating that the social token used by the sender has been involved in one or both of past possible fraud or past account abuse.
10 and 12-14. identifying at least one additional social token associated with the sender; and accessing data associated with each of the at least one additional social token, wherein the health score for the transaction is further based at least in part on the data associated with each of the at least one additional social token.
15. further comprising: locking the social token used by the sender from being useable.
17. wherein the instructions further cause the one or more processors to: determine that the health score for the transaction is too low to approve; and transmit a notification to the sender to confirm details of the transaction to confirm that the transaction is legitimate and not fraudulent.
18. wherein: the data associated with the transaction initiated by the sender comprises a social token used by a receiver of the transaction; and the instructions further cause the one or more processors to: generate a health score for the social token used by the receiver; and generate a risk score for the transaction based at least in part on the health score for the social token used by the sender and the health score for the social token used by the receiver.
19. wherein: the risk score comprises a confirmation that the health score for the social token used by the sender and the health score for the social token used by the receiver are above an established threshold.
20. wherein: the social token comprises at least one of a phone number, an email address, a QR code assigned to the sender, a peer-to-peer payment system user handle, or a social media handle.
21. wherein: the data associated with the transaction comprises an amount of the transaction, a device used to initiate the transaction, a location of the transaction, or a payee of the transaction.
6. wherein: the health score for the social token used by the sender comprises at least one of a general health score that assesses the social token used by the sender in general, a payer health score that represents a score for the social token used by the sender when used by the sender as a payer in a transaction, or a payee health score that represents a score for the social token used by the sender when used by the sender as a payee in a transaction.
This preamble is the same,
This limitation is essentially the same.
This limitation is essentially the same
This limitation is essentially the same
This limitation is essentially the same.
This limitation is essentially the same
This limitation is essentially the same
This limitation is essentially the same
This limitation is essentially the same
This limitation is essentially the same
This limitation is the same
This limitation is essentially the same
This limitation is essentially the same as the past possible fraud or past account abuse is indicative of a level of risk for use of the social token by the sender as a payee in a transaction
This limitation is essentially the same
This limitation is essentially the same
This limitation is essentially the same
This limitation is essentially the same
This limitation is essentially the same
This limitation is essentially the same
This limitation is essentially the same, identifying the sender as a payee in a transaction
This limitation is essentially the same
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 2-21, 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 2-8 are directed to a machine (i.e., a system), claims 9-16 are directed to a process (i.e., a method), and claims 16-21 is directed to a product (i.e., a non-transitory computer-readable medium), therefore, these claims fall within the four statutory categories of invention. Thus, the eligibility analysis proceeds to Step 2A.1.
The limitations of independent claim 9, which is representative of independent claims 2 and 15, have been denoted with letters by the Examiner for easy reference. The judicial exceptions recited in claim 9 are identified in bold below:
[A] A method for the health of social tokens, comprising:
[B] receiving data associated with a sender, wherein:
[C] the data associated with the sender is used by a data assessment system to generate an account associated with the sender; and
[D] the data associated with the sender comprises a social token used by the sender;
[E] utilizing the social token to retrieve account data associated with one or more accounts maintained at one or more entities, wherein the account data comprises data pertaining to use of the social token in transactions conducted using each of the one or more accounts;
[F] analyzing the data pertaining to use of the social token used by the sender in transactions conducted using each of the one or more accounts to generate a health score for the social token used by the sender, wherein the health score for the social token used by the sender is indicative of a level of risk for use of the social token by the sender as a payer in a transaction;
[G] receiving, from the sender, data associated with a transaction initiated by the sender;
[H] determining a health score for the transaction based at least in part the health score for the social token used by the sender and data associated with the transaction; and
[I] determining whether the transaction should be approved or rejected based at least in part on the health score for the transaction.
Limitations A-I under the broadest reasonable interpretation covers steps or
functions of certain methods of organizing human activity, specifically managing
personal/commercial behavior (e.g., receiving, generating, utilizing, analyzing, and
determining). For example, the disclosure establishes collecting data of sender’s social
behavior and using the data to generate a score of risk level of the sender to
determining approving or rejecting the completion of the transaction, which is a
form of commercial and legal activities, fits squarely within the “certain methods of
organizing human activity” grouping of abstract ideas. Therefore, limitations A and I recite at least one abstract idea. Accordingly, claim 1, recite at least two abstract ideas and the analysis proceed to Step 2A.2.
The judicial exception is not integrated into a practical application. In particular,
claims 9, recites the additional elements in bold below:
[A] A method for the health of social tokens, comprising:
[B] receiving data associated with a sender, wherein:
[C] the data associated with the sender is used by a data assessment system to generate an account associated with the sender; and
[D] the data associated with the sender comprises a social token used by the sender;
[E] utilizing the social token to retrieve account data associated with one or more accounts maintained at one or more entities, wherein the account data comprises data pertaining to use of the social token in transactions conducted using each of the one or more accounts;
[F] analyzing the data pertaining to use of the social token used by the sender in transactions conducted using each of the one or more accounts to generate a health score for the social token used by the sender, wherein the health score for the social token used by the sender is indicative of a level of risk for use of the social token by the sender as a payer in a transaction;
[G] receiving, from the sender, data associated with a transaction initiated by the sender;
[H] determining a health score for the transaction based at least in part the health score for the social token used by the sender and data associated with the transaction; and
[I] determining whether the transaction should be approved or rejected based at least in part on the health score for the transaction.
[J] Additionally, claim 2 recites “A system for determining the health of social tokens, the system comprising:”
[K] And claim 16 recites “A non-transitory computer-readable medium having instructions stored thereon that, when executed by one or more processors, cause the one or more processors to:”
The additional elements (“a data assessment system”, “A system for determining the health of social tokens, the system comprising:”, “A non-transitory computer-readable medium having instructions stored thereon that, when executed by one or more processors, cause the one or more processors to:”), are no more than a generic computer performing operations to automate the data assessment computer. When the additional elements are considered individually and as an ordered combination, the claim as a whole, amounts to no more than or mere instructions to implement an abstract idea on a device/computer, or merely uses a computer as a tool to perform an abstract idea. Accordingly, the additional element(s) do not integrate the abstract idea into a practical application because they do not recite any additional elements indicative of integration into a practical application. Rather, the claim as whole generally links the judicial exception to a technological environment (e.g., “a data assessment system”, “A system for determining the health of social tokens, the system comprising:”, “A non-transitory computer-readable medium having instructions stored thereon that, when executed by one or more processors, cause the one or more processors to:”), defined by high level recitations of a computer and the Internet. Therefore, the claim is directed to an abstract idea and the analysis proceeds to Step 2B.
The additional elements, both individually and as an ordered combination, do not amount to significantly more than the judicial exception because the outcome of the considerations at Step 2B will be the same when the considerations from Step 2A.2 are reevaluated. As discussed under Step 2A.2, the additional element(s) amount to no more than generally link the abstract idea to a technological environment through “instructions” performed by a generic computer. Because those instructions embody the abstract idea, the claim itself is merely a recitation of the abstract idea and an instruction to “apply it” on a computer. This is not enough to provide an inventive
concept. Therefore, claims 2, 9 and 16 are not patent eligible.
Dependent claims 3-6, further recites wherein: the data associated with the transaction initiated by the sender comprises a social token used by a receiver of the transaction; and the instructions further cause the one or more processors to generate a health score for the social token used by the receiver; wherein: the health score for the transaction is further determined based at least in part the health score for the social token used by the receiver; wherein: generating the health score for the social token used by the receiver comprises analyzing data associated with the receiver, data pertaining to use of the social token used by the receiver in one or more prior transactions, and account data received from the one or more entities; wherein: the health score for the social token used by the sender comprises at least one of a general health score that assesses the social token used by the sender in general, a payer health score that represents a score for the social token used by the sender when used by the sender as a payer in a transaction, or a payee health score that represents a score for the social token used by the sender when used by the sender as a payee in a transaction. Under the broadest reasonable interpretation covers steps or functions of certain methods of organizing human activity, specifically managing personal/commercial behavior. For example, the claims establishes, collecting data of sender’s social behavior and using the data to generate a score of risk level of the sender to determine approving or rejecting the completion of the transaction, which is a form of commercial and legal activities, fits squarely within the “certain methods of organizing human activity” grouping of abstract ideas in prong one of Step 2A. The 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, claims 3-6 are not patent eligible.
Dependent claims 7-8, further recites wherein: the account data comprises at least one of data associated with how long the social token used by the sender has been established, data associated with historical users of the social token used by the sender and information associated with each of those users, network behaviors associated with social token used by the sender over time, a velocity of payments associated with the social token used by the sender, a number of times the social token used by the sender has registered to a new financial institution over a certain time period, a number of times the social token used by the sender has registered to a new demand deposit account over a certain time period, or behavioral patterns associated with use of the social token used by the sender; wherein: receive data indicating that the social token used by the sender has been involved in one or both of past possible fraud or past account abuse; and the health score for the social token used by the sender is determined based at least in part on the data indicating that the social token used by the sender has been involved in one or both of past possible fraud or past account abuse. Under the broadest reasonable interpretation covers steps or functions of certain methods of organizing human activity, specifically managing personal/commercial behavior. For example, the claims establishes, collecting data of sender’s social behavior/attribute and using the data to generate a score of risk level of the sender to determine approving or rejecting the completion of the transaction, which is a form of commercial and legal activities, fits squarely within the “certain methods of organizing human activity” grouping of abstract ideas in prong one of Step 2A. The 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, claims 7-8 are not patent eligible.
Dependent claims 10-15, further recites further comprising: identifying at least one additional social token associated with the sender; and accessing data associated with each of the at least one additional social token, wherein the health score for the transaction is further based at least in part on the data associated with each of the at least one additional social token; wherein: the health score of the social token used by the sender further comprises a score that is indicative of a level of risk for use of the social token used by the sender as a payee in a transaction; wherein: the health score of the social token used by the sender is determined based at least in part on usage patterns of the social token used by the sender in transactions conducted using each of the one or more accounts; wherein: the health score of the social token used by the sender is determined based at least in part on a business type of the sender; wherein: the health score of the social token used by the sender is determined based on a plurality of transaction characteristics; and at least some of the plurality of transaction characteristics are weighted differently; wherein: the health score of the social token used by the sender is determined based on a plurality of transaction characteristics; and at least some of the plurality of transaction characteristics are weighted differently; locking the social token used by the sender from being useable. Under the broadest reasonable interpretation covers steps or functions of certain methods of organizing human activity, specifically managing personal/commercial behavior. For example, the claims establishes, collecting data of sender’s social behavior and using the data to generate a score of risk level of the sender to determine approving or rejecting the completion of the transaction, which is a form of commercial and legal activities, fits squarely within the “certain methods of organizing human activity” grouping of abstract ideas in prong one of Step 2A. The 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, claims 10-15 are not patent eligible.
Dependent claims 17-21, further recites wherein the instructions further cause the one or more processors to: determine that the health score for the transaction is too low to approve; and transmit a notification to the sender to confirm details of the transaction to confirm that the transaction is legitimate and not fraudulent; wherein: the data associated with the transaction initiated by the sender comprises a social token used by a receiver of the transaction; and the instructions further cause the one or more processors to: generate a health score for the social token used by the receiver; and generate a risk score for the transaction based at least in part on the health score for the social token used by the sender and the health score for the social token used by the receiver; wherein: the risk score comprises a confirmation that the health score for the social token used by the sender and the health score for the social token used by the receiver are above an established threshold; wherein: the social token comprises at least one of a phone number, an email address, a QR code assigned to the sender, a peer to peer payment system user handle, or a social media handle; wherein: the data associated with the transaction comprises an amount of the transaction, a device used to initiate the transaction, a location of the transaction, or a payee of the transaction. Under the broadest reasonable interpretation covers steps or functions of certain methods of organizing human activity, specifically managing personal/commercial behavior. For example, the claims establishes, collecting data of sender’s social behavior and using the data to generate a score of risk level of the sender to determine approving or rejecting the completion of the transaction, which is a form of commercial and legal activities, fits squarely within the “certain methods of organizing human activity” grouping of abstract ideas in prong one of Step 2A. The 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, claims 17-21 are not patent eligible.
In summary, the dependent claims considered both individually and as an
ordered combination do not provide meaningful limitations to transform the abstract idea
into a patent eligible application of the abstract idea such that the claims amount to
significantly more than the abstract idea itself. The claims do not recite an improvement
to another technology or technical field, an improvement to the functioning of the
computer itself, or provide meaningful limitations beyond generally linking an abstract
idea to a particular technological environment. Therefore, the claims are rejected under
35 U.S.C. § 101 as being directed to non-statutory subject matter.
Prior Art Analysis
This application contains Allowable subject matter based on the similar claim limitation that are not patentably distinct from the Allowed patent 12/211,049. Independent claims 2, 9 and 16 recites Allowable limitations “generate a health score for the social token used by the sender, wherein the health score for the social token used by the sender is indicative of a level of risk for use of the social token by the sender as a payer in a transaction;” and “determining a health score for the transaction based at least in part the health score for the social token used by the sender and data associated with the transaction;” Upon further search, Examiner is unable to find prior art that teaches these limitations. Therefore, there is no 103 rejection at this stage of prosecution.
Conclusion
The prior art made of record and not relied upon:
1) (US 20230353530 A1) – Schmid et al., Systems and Methods for
Generating Automatically Suggested Recommendations Based on Aggregated Recommendations within a Social Networking System - relates to the field of social networks. More particularly, the present technology relates to techniques for generating recommendations associated with social networking systems.
2) (US Pat. 11810105 B2) – Vyas et al., System And Method For Authorizing And Provisioning A Token To An Appliance – relate generally to a system and method for providing an appliance with an original personal account number, and, in one particular embodiment, to a system and method for authorizing and provisioning a token to an appliance for conducting transactions.
3) (US 20230132878 A1) – Perez et al., Methods and Apparatus to Analyze and Adjust Demographic Information – relates generally to audience measurements and, more particularly, to methods and apparatus to analyze and adjust demographic information of audience members.
4) (US 20180336553 A1) – Brudnicki et al., Facilitating a Fund Transfer between User Accounts - relates to facilitating a fund transfer between user accounts, including to facilitating a fund transfer between user accounts using anonymous receive tokens.
5) (US 20120278164 A1) – Spivack et al., Adaptive System Architecture for Identifying Popular Topics from messages - relates generally to analysis of messages and associated content in a network or across networks to retrieve useful information, and in particular, useful information to recommend content placement such as advertisement placement.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VINCENT IDIAKE whose telephone number is (571)272-1284. The examiner can normally be reached on Mon-Fri from 10:30AM to 7:30PM ET.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, PATRICK MCATEE, can be reached at telephone number 571-272-7575. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated-interview-request-air-form
/V.I./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698