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 statements are in compliance with the provisions of 37 CFR § 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Due to extremely voluminous prior art citation by the applicant, the examiner has only given each reference a cursory review. Applicant is reminded that the cloaking of a clearly relevant reference by inclusion in a long list of citations may not comply with the applicant’s duty of disclosure. Penn Yan Boats, Inc. v. Sea Lark Boats, Inc., 359 F. Supp. 948 (S.D. Fla. 1972). See also, dicta from Molins PLC v. Textron, Inc., 48 F.3d 1172 (Fed. Cir. 1995), stating that forcing the examiner to find “a needle in a haystack” is “probative of bad faith.” Therefore, it is recommended that if any information that has been cited by applicant in the information disclosure statements is known to be material for patentability as defined by 37 C.F.R. § 1.56, applicant should present a concise statement as to the relevance of those particular documents cited therein.
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, 4, 8, 9, 12, 14, 19, and 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).
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]
1,12
modify, responsive to receiving the first request, the listing to indicate that the user of the user account has denied the computing device access to the data corresponding to the user account
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.
Lovin/Krishna fails to explicitly disclose: “deny the second request from the computing device to access the data corresponding to the 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. After removal of a device 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 device from the interoperability network.
Claims 2, 3, 5-7, 10, 11, 13, and 15-18 are rejected under 35 U.S.C. 103 as being unpatentable over Lovin in view of Krishna and further in view of Purves (US 2013/0346302 A1).
Lovin/Krishna fails to explicitly disclose but Purves teaches:
Claim
Limitation
Representative disclosure in Purves
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 above 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 user adoption, to one of ordinary skill in the art at the time of the invention.
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.
Applicant further argues that Krishna “does not teach ‘modify[ing] [a] listing to indicate that the user of the user account has denied the computing device access to the data corresponding to the user account,’ as claimed (with emphasis added).” The examiner respectfully disagrees. Krishna teaches removing a computing device from the list. The purpose of the list is to list devices with access to data corresponding to a user account. Removal from this list constitutes an indication that the user account has denied the device access to that data. At most, the difference amounts to a difference in nonfunctional descriptive material, as the functional effect of removing the device from the list is the same as creating any other sort of indication of denial of access. As such, this difference fails to distinguish from the prior art.
For the above reasons, the prior art rejections are maintained, as modified in response to applicant’s amendment.
Conclusion
Applicant's amendment necessitated the new grounds of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMIE KUCAB whose telephone number is (571)270-3025. 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 by telephone 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) Form at https://www.uspto.gov/patents/uspto-automated-interview-request-air-form.
/JAMIE R KUCAB/Primary Examiner, Art Unit 3699
Prosecution Insights