DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Acknowledgements
Applicant’s response filed March 11, 2026 is acknowledged.
Claims 1-20 are pending in the application.
Claims 1-20 are examined below.
Examiner Request
Applicant is requested to indicate where in the specification there is support for amendments to claims should applicant amend. The purpose of this is to reduce potential 35 USC 112(a) or 35 USC 112, 1st paragraph issues that can arise when claims are amended without support in the specification. Examiner thanks applicant in advance. See also relevant portions of MPEP 2163.II.A:
With respect to newly added or amended claims, applicant should show support in the original disclosure for the new or amended claims. See, e.g., Hyatt v. Dudas, 492 F.3d 1365, 1370, n.4 (Fed. Cir. 2007) (citing MPEP § 2163.04 which provides that a "simple statement such as ‘applicant has not pointed out where the new (or amended) claim is supported, nor does there appear to be a written description of the claim limitation ‘___’ in the application as filed’ may be sufficient where the claim is a new or amended claim, the support for the limitation is not apparent, and applicant has not pointed out where the limitation is supported."); see also MPEP § 714.02 and § 2163.06 ("Applicant should ... specifically point out the support for any amendments made to the disclosure."); and MPEP § 2163.04 ("If applicant amends the claims and points out where and/or how the originally filed disclosure supports the amendment(s), and the examiner finds that the disclosure does not reasonably convey that the inventor had possession of the subject matter of the amendment at the time of the filing of the application, the examiner has the initial burden of presenting evidence or reasoning to explain why persons skilled in the art would not recognize in the disclosure a description of the invention defined by the claims.").
Information Disclosure Statement
The attached information disclosure statement is in compliance with the provisions of 37 CFR § 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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 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 statute.
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 of this title, 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 following is a quotation of 35 U.S.C. 103(a) (pre-AIA ) which forms the basis for all obviousness rejections set forth in this office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Lovin (US 2017/0249478 A1) in view of Krishna (US 2014/0149771 A1) and further in view of Purves (US 2013/0346302 A1).
Lovin discloses as follows:
Claim
Limitation
Representative disclosure in Lovin
1,12
A service provider computing system comprising:
DPSP 210
1,12
a network interface configured to communicate via a telecommunications network
NETWORKING INTERFACE 220, Fig. 2 and associated text
1,12
one or more processors and a memory having stored thereon instructions which, when executed by the one or more processors, cause the service provider computing system to:
"Various functions described herein as being performed by one or more entities may be carried out by hardware, firmware, and/or software. For instance, some functions may be carried out by a processor executing instructions stored in memory." [0029]. See also Fig. 2 (esp. STORAGE 250) and associated text
1,12
receive, via the network interface, an access request from an application installed on a computing device in the listing, the access request identifying the user account and data corresponding to the user account
"service provider 124 may request access to some personal data of the user via DPSP 130" [0036]
1,12
in response to verifying the access request, use the network interface to transmit the data to the application installed on the computing device
"DPSP 130 may request the approval from the user (e.g., via user device 112) for service provider 122 to access the user's "Date of Birth." If the user issues an approval, DPSP 130 may then request service provider 124 and/or service provider 126 to forward the user's data related to "Date of Birth" to service provider 122." [0039]"Service providers 122 and 124 through 126 may be discrete from user devices 112 and 114 through 116 and DPSP 130 or may be incorporated and/or integrated into at least one of those components." [0035]
1,12
receive, from the computing device, a second request to access the data corresponding to the user account
"service provider 124 may request access to some personal data of the user via DPSP 130" [0036]
1,12
receive, from the user device of the user, a third request to delete the user account for which the data was provided to the application
"service provider 126 may delete or modify an item of personal data of the user upon the user's request via DPSP 130." [0036]"a user may ... set up another rule to share limited financial information with e-commerce vendors" [0057]"user may send a request to the DPSP to modify an existing map sheet, such as setting up or altering a rule for data sharing, purging user data from a selected service provider" [0069]
1,12
generate, responsive to receiving the third request, a command that requests deletion of the user account and the data from the application
1,12
use the network interface to transmit the command to the application to have the application, consistent with the third request from the user device, delete the user account and the data received from the service provider computing system
4,14
wherein the command instructs the application to delete the data from all computer-readable storage media controlled by the application
"user may send a request to the DPSP to modify an existing map sheet, such as setting up or altering a rule for data sharing, purging user data from a selected service provider" [0069]
6,16
wherein the data identifies a credit or debit card, and wherein the use corresponds with use of the credit or debit card in an identified category of financial transactions
"[0073] As an example, during an online purchase from the first service provider, which has no existing relationship with the user, the user is normally required to input the payment information, such as a credit card, in order to complete the transaction. However, with the framework as described in connection with FIG. 1, this process of inputting the payment information can be made transparent to the user. Namely, the first service provider now can submit a request for the payment information to the DPSP. Subsequently, the DPSP may explicitly solicit the user to approve the specific access request from the first service provider.""a user may ... set up another rule to share limited financial information with e-commerce vendors" [0057]
Lovin fails to explicitly disclose but Krishna teaches:
Claim
Limitation
Representative disclosure in Krishna
1,12
maintain a listing identifying one or more computing devices which have been granted access to a user account associated with a user
"the device management engine 203 uses the user identifiers in the access control list and queries the device inventory service 265 for a list of devices associated with the users participating in the calendar even" [0094]
1,12
receive, from a user device of the user, a first request that identifies the computing device and indicates that the user of the user account has denied the computing device access to the user account
"The device inventory service 265 receives requests to add, remove and update devices in the network 104 from the workflow engine 201" [0121]
8,19
wherein the listing further identifies one or more computing devices which have been granted access to the data corresponding to the user account
"the device management engine 203 uses the user identifiers in the access control list and queries the device inventory service 265 for a list of devices associated with the users participating in the calendar even" [0094]
9,20
determine that a calendar application has been granted access to data corresponding to the user account
See [0147]
9,20
transmit, to the calendar application, a list of upcoming payments owed by the user for display by the calendar application
It would have been obvious to one having ordinary skill in the art at the time of the invention to modify Lovin to include the device access control list and calendar interoperability of Krishna in order to achieve the predictable results of increased convenience of access and increased features, respectively. Both of which would lead to increased user adoption.
The combination Lovin/Krishna fails to explicitly disclose but Purves teaches:
Claim
Limitation
Representative disclosure in Purves
1,12
modify, responsive to receiving the first request, the listing to include an indicator that specifies the user of the user account has denied the computing device access to the data corresponding to the user account
"A social application data request may be a request to retrieve a list of social media applications associated with or available using a user or third party's social media credentials. In one embodiment, the social application data request is send to a social media server 10403, which may receive the request and retrieve available social media application profiles, e.g., 10413. For example, in one embodiment a comma delimited list of all applications include an application name, application permission, application widget integration, and/or the like may be returned. The social media server may prepare a social application data response package using the retrieved social media application profiles, e.g., 10414, and transmit the response to Bill Pay server 10402. In one embodiment, Bill Pay server 10402 may receive the response and extract the available social media application profiles, e.g., 10415." [0295]
2,13
wherein the command includes an API call to the application, wherein the API call identifies the user and the data to be deleted
"Bill-Pay server 220 may exchange information, e.g., via a Visa card API, to biller sites 210C, including consumer information 246a (which may take a form similar to 241), billing information 246b (which may take a form similar to 242), promotion information 246c and/or the like." [0237]. See also [0297], [0427], and Table 1
3,18
wherein the access request is an API call transmitted by the application to the service provider computing system
5,15
wherein the second request identifies a selection made, via a graphical interface presented by a client application running on the user device, between permitting a use of the data and prohibiting the use of the data
Figs. 207b or 2012 and associated text"Bill-Pay server 220 may exchange information, e.g., via a Visa card API, to biller sites 210C, including consumer information 246a (which may take a form similar to 241), billing information 246b (which may take a form similar to 242), promotion information 246c and/or the like." [0137]
7,17
wherein the identified category of financial transactions is foreign transactions
"the consumer may be given additional options for restricting reference transactions if the merchant is a new merchant, located in a foreign country, has a history of fraudulent transactions, or other conditions are present that may be cause for enhanced security" [0412]
10
wherein the listing further comprises one or more applications installed on the user device and an indicator for each respective application to indicate whether the respective application has been granted access to data corresponding to the user account
"A social application data request may be a request to retrieve a list of social media applications associated with or available using a user or third party's social media credentials. In one embodiment, the social application data request is send to a social media server 10403, which may receive the request and retrieve available social media application profiles, e.g., 10413. For example, in one embodiment a comma delimited list of all applications include an application name, application permission, application widget integration, and/or the like may be returned. The social media server may prepare a social application data response package using the retrieved social media application profiles, e.g., 10414, and transmit the response to Bill Pay server 10402. In one embodiment, Bill Pay server 10402 may receive the response and extract the available social media application profiles, e.g., 10415." [0295]
11
wherein the listing further comprises one or more applications installed on the user device and an indicator for each respective application to indicate whether the respective application has been granted access to data corresponding to the user account
It would have been obvious to one having ordinary skill in the art at the time of the invention to modify Lovin/Krishna to include the account and application level access control and related features of Purves because all the claimed elements/steps were known in the prior art and one skilled in the art could have combined the elements/steps as claimed by known methods with no change in their respective functions, and the combination would have yielded predictable results, such as increased flexibility leading to increased user adoption, to one of ordinary skill in the art at the time of the invention.
Lovin/Krishna/Purves fails to explicitly disclose: “deny the second request from the computing device to access the data corresponding to the user account based on modifying the listing” (or similar). However, this denial would have been obvious because “a person of ordinary skill has a good reason to pursue the known options within his or her technical grasp. If this leads to the anticipated success, it is likely the product not of innovation but of ordinary skill and common sense.” KSR Int’l Co. v. Teleflex Inc. 82 USPQ2d 1385, 1397. Lovin discloses receiving a request for data as discussed above. Krishna teaches removing devices from an interoperability network as discussed above. And Purves adds user account and application level access controls. After removal of an account from the interoperability network and in response to a further request for data to that device, there are only two possible responses: permitting or denying that request. Therefore, it would have been obvious to deny that request, because it is one of two possible responses, and to do otherwise would defeat the purpose of removing the account from the interoperability network.
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 filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual 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/apply/applying-online/eterminal-disclaimer.
Claims 1-20 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 1-18 of U.S. Patent No. 12,067,147. Although the conflicting claims are not identical, they are not patentably distinct from each other because they differ merely in terminology, nonfunctional descriptive material, intended use, etc.
Citation of Relevant Prior Art
All references listed on form PTO-892 are cited in their entirety. The following prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Mutha (US 2015/0301903 A1) discloses for managing user data, including user-requested global deletion of selections of their data ([0306]).
Goyal (US 2008/0134347 A1) discloses an app and dataset manager, including access based on mappings of users to devices and users to apps (see Fig. 1 and associated text).
Baptist (US 2014/0075112 A1) discloses a system for managing user data including access based on device ID (see [0335]).
Use of APIs is considered to be applicant-admitted prior art (see the action mailed September 24, 2021 in prior-filed application 16/211,391).
Response to Amendments and Arguments
The examiner expresses his appreciation for applicant’s specific citations to the specification indicating where applicant believes support for the claim amendments can be found. The examiner's search for support for the claim amendments was not limited to these citations.
Regarding the prior art rejections, applicant argues that the newly added limitations overcome the art of record. The examiner respectfully disagrees. See the above prior art rejections for a mapping of the previously applied art to the newly added limitations.
For the above reasons, the prior art rejections are maintained, as modified in response to applicant’s amendment.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMIE KUCAB whose telephone number is (571)270-. The examiner can normally be reached Monday through Friday, 9 a.m. to 4:30 p.m. ET. The examiner’s email address is Jamie.Kucab@USPTO.gov. See MPEP 502.03 regarding email communications. Following is the sample authorization for electronic communication provided in MPEP 502.03.II: “Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with the undersigned and practitioners in accordance with 37 CFR 1.33 and 37 CFR 1.34 concerning any subject matter of this application by video conferencing, instant messaging, or electronic mail. I understand that a copy of these communications will be made of record in the application file.” Without such an authorization in place, an examiner is unable to respond via email.
If attempts to reach the examiner are unsuccessful, the examiner’s supervisor, Neha Patel, can be reached at telephone number (571) 270-1492. 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) at http://www.uspto.gov/interviewpractice.
/JAMIE R KUCAB/Primary Examiner, Art Unit 3699
Prosecution Insights