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 .
This is a non-final office action.
Claims 1-20 are pending.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 10/02/2025 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Continuation
This application is a continuation application of U.S. application no. 17/969,797 filed on 10/20/2022, now US Patent No. 12,380,437 (Parent Application), which is a continuation application of U.S. application no. 17/676,328 filed on 2/21/2022, now US Patent No. 12,211,033 (Parent Application), which claims the benefit of and priority of U.S. provision application no. 63/181,861 filed on April 29, 2021 and also claims the benefit of and priority of U.S. provision application no. 63/152,581 filed on February 23, 2021. See MPEP §201.07. In accordance with MPEP §609.02 A. 2 and MPEP §2001.06(b) (last paragraph), the Examiner has reviewed and considered the prior art cited in the Parent Application. Also, in accordance with MPEP §2001.06(b) (last paragraph), all documents cited or considered ‘of record’ in the Parent Application are now considered cited or ‘of record’ in this application. Additionally, Applicant(s) are reminded that a listing of the information cited or ‘of record’ in the Parent Application need not be resubmitted in this application unless Applicant(s) desire the information to be printed on a patent issuing from this application. See MPEP §609.02 A. 2.
Specification
The use of the term, i.e., Apple, Google, Samsung, Citrix, Azure, etc., which are trade name(s) or mark(s) used in commerce, has been noted in this application. The term should be accompanied by the generic terminology; furthermore the term should be capitalized wherever it appears or, where appropriate, include a proper symbol indicating use in commerce such as ™, SM , or ® following the term.
Although the use of trade names and marks used in commerce (i.e., trademarks, service marks, certification marks, and collective marks) are permissible in patent applications, the proprietary nature of the marks should be respected and every effort made to prevent their use in any manner which might adversely affect their validity as commercial marks.
The applicant is advised to review the Specification to identify all the trademark expressions and properly mark the expressions as noted above.
Claim Objection
Per claim 6, the recitation of “providing, by the second device, to the first device, and indication that the device access token has been stored in the secure storage element of the second device” should be amended to recite “providing, by the second device, to the first devicean indication that the device access token has been stored in the secure storage element of the second device”.
As per claim 16, the recitation of “provide, to the first device, and indication that the device access token has been stored in the secure storage element of the second device” should be amended to replace “and” with “an”.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 6 and 16 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Per claim 6, the claim recites in part providing, by the second device, to the first device, and indication that the device access token has been stored in the secure storage element of the second device. The claim is rejected as while the specification find support that the device access token being stored in the secure storage element, there is no support that the second device, i.e., secondary smart device 240, providing to the first device, i.e., smart device 106, an indication that the device access token has been stored in the secure storage element of the second device.
Claim 16 is significantly similar to claim 6. As a result, the claim 16 is also rejected.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 9 and 19 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Per claim 9, the claim recites The method of claim 8, further comprising generating, by the first device, the device access token to encode the account restriction applicable to the second device or the second software application. The examiner submits that claim 8 is dependent on claim 1 which recites in part generating, by the first device, a device access token based on a device identifier corresponding to the second device.
As such, when claim 9 is written as an independent form, the claim recites … generating, by the first device, a device access token based on a device identifier corresponding to the second device; and generating, by the first device, the device access token to encode the account restriction applicable to the second device or the second software application … In other word, the device access token is generated twice which renders the claim to be indefinite. The applicant is advised to amend claim 9 to recite “The method of claim 8, wherein the generating, by the first device, the device access token further includes encoding in the device access token.”
Claim 19 is significantly similar to claim 9, hence also rejected.
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 abstract idea without significantly more.
MPEP 2106 provides step(s) in determining eligibility under 35 U.S.C. § 101. Specifically, it must be determined whether the claim is directed to one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter. If the claim does fall within one of the statutory categories, it must then be determined whether the claim is directed to a judicial exception (i.e., law of nature, natural phenomenon, and abstract idea), and if so, it must additionally be determined whether the claim is a patent-eligible application of the exception. If an abstract idea is present in the claim, any additional elements in the claim must integrate the judicial exception into a practical application. If not, the inquiry continues to see whether any element or combination of elements in the claim must be sufficient to ensure that the claim amounts to significantly more than the abstract idea itself. Examples of abstract ideas include mathematical concepts, mental processes, and certain methods of organizing human activities.
Under Step 1, claims 1-10 are directed to a method (i.e., process) while claims 11-20 are directed to a to a system. Thus, the claimed inventions are directed towards one of the four statutory categories under 35 USC § 101. Nevertheless, the claims also fall within the judicial exception of an abstract idea without significantly more.
Step 2A, 1st prong:
Claim 1 recites: A method comprising:
a) receiving, by a first device via a first software application executing on the first device, a request to enroll a second device in a server-to-device secure data exchange ecosystem, wherein the second device is locally paired to the first device;
b) generating, by the first device, a device access token based on a device identifier corresponding to the second device;
c) providing, by the first device, the device access token to the second device;
d) receiving, by the second device, a transaction request from a second software application executing on the second device;
e) transmitting, by the second device, to a computing system, the device access token and the transaction request, wherein the transaction request causes the computing system to: (i) parse the device identifier corresponding to the second device from the device access token, and (ii) generate an electronic message for transmission to the second device;
f) receiving, by the second device, from the computing system, the electronic message responsive to the transaction request; and
g) providing, by the second device, to the second software application, a response to the transaction request based on the electronic message.
(Emphasis added on the additional element(s))
Under the broadest reasonable interpretation, the claim recites a process between two groupings, i.e., a first group and a second group, particularly g) providing of a response to a transaction request based on a message received from a resource provider to an entity belonging to the second group. The claim achieves this by a) receiving by a first group via first entity within the first group a request to enroll a second group in a secure data exchange, wherein the first group and the second group is locally paired; b) generating by the first group an group access token based on a group identifier corresponding to the second group; c) providing, by the first group, the group access token to the second group; d) receiving, by the second group, a transaction request from a second entity within the second group; e) transmitting, by the second group to the resource provider, the group access token and the transaction request, wherein the transaction request causes the resource provider to: (i) parse the group identifier corresponding to the second group from the group access token, and (ii) generate a message for transmitting to the second group; and f) receiving, by the second group, from the resource provider, the message responsive to the transaction request. Finally, g) a response to the transaction request based on the message is provided to the second entity within the second group.
Accordingly, the claim recites a certain method of organizing human activity, i.e., managing relationships or interactions between people by following rules in provision of resource, resulting in recitation of abstract idea.
Under the Step 2A (prong 2), this judicial exception is not integrated into a practical application. Specifically, the additional elements in the claim(s), i.e., devices, software application executing on device(s), server-to-device, computing system, amount to no more than mere instructions to implement the abstract idea and/or merely uses a computer as a tool to perform an abstract idea – see MPEP 2106.05(f). There is no indication that the claim improves upon the recited system’s component(s) individually or in combination individually or in combination.
Under Step 2B, examiners should evaluate additional elements individually and in combination to determine whether they provide an inventive concept (i.e. whether the additional elements amount to significantly more than the exception itself). Here, the claim(s) do not include additional elements that are sufficient to amount to significantly more than the judicial exception. Specifically, the claim(s) as a whole, taken individually and in combination, do not provide an inventive concept. As explained above with respect to the integration of the abstract idea into a practical application, the additional elements used to perform the claimed judicial exception amount to no more than mere instructions to implement the abstract idea and/or merely uses a computer as a tool to perform an abstract idea. Mere instructions to implement the abstract idea on a computer, or merely using the computer as a tool to perform an abstract idea to apply the exception using a generic computer component cannot provide an inventive concept. Looking at the limitations as a combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of the elements improves the functioning of the recited computer component(s).
Dependent claims 2-10 and 12-20 further expand on the abstract idea. The additional elements of secure storage element recited in 5-7 and 15-17 amounts to no more than use of computer component to perform the abstract idea of storing and retrieving the group access token.
The applicant is advised to functionally tie the account restrictions applicable to the second device or the second software application encoded in the device access token (i.e., claims 9 and 19) to the process positively in the method claim and to the system comprising the first device and the second device in the system claim in order to address the 101 rejections.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries 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.
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.
Claim(s) 1, 4-5, 7-11, 14-15, and 17-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20190068575 A1 (“Vongsouvanh”) in view of US 2015/0007283 A1 (“Brugger”).
Per claims 1 and 11, Vongsouvanh discloses a method comprising:
receiving, by a first device via a first software application executing on the first device, a request to enroll a second device in a server-to-device secure data exchange ecosystem, wherein the second device is locally paired to the first device (see Fig. 1; [0023]-[0024], by receiving from the user to engage, the computing device receives a request to enroll a second device, i.e., client device in a server-to-device secure data exchange ecosystem; [0026], the client device is further configured to provide authorization requestion for the authorization flow … a request for authorization to exchange information with a service; [0027]-[0028], display prompt that provides user of computing device with the option to accept or deny authorization request; [0030], provides client device 110 with access to exchange information with resource service 120 that hosts a protected resource associated with the security credential and with user 132);
generating a device access token ([0031]-[0032], access token includes data defining a specific scope … to obtain access to protected resources that are hosted by resource service 120; [0076], generating access token);
providing, by the first device, the device access token to the second device ([0034], client device 110 receives an access token; [0043], computing device 100 sends access token 402 to client device 110; [0044], client device 110 receives access token 402);
receiving, by the second device, a transaction request from a second software application executing on the second device ([0017], the client device may prompt the user, by a user-interface of the client device, to locate the mobile computing device within the defined range of the tag device in order to engage the tag device; [0044], a request for a protected resource; [0056]; [0072], relay access token to the client device; [0076]);
transmitting, by the second device, to a computing system, the device access token and the transaction request, wherein the transaction request causes the computing system to: (ii) generate an electronic message for transmission to the second device ([0034], the client device uses communication pathway 124 to present the access token to resource service 120 to access protected resources in accordance with the scope of the access token; [0044], client device presents token 402 to resource provider 120 with a request … resource provider 120 validates access token 402; [0077]; [0079]) ;
receiving, by the second device, from the computing system, the electronic message responsive to the transaction request (see [0020], enable a client device to obtain access to resources; [0030], provides client device 110 with access to exchange information with resource service 120 that hosts a protected resource associated with the security credential and with user 132; [0033], protected resources may include any digital information or hosted resources associate with user 132 such as .. financial information …; [0044], the resource service 120 serves protected resource; [0077]; [0079]); and
providing, by the second device, to the second software application, a response to the transaction request based on the electronic message (Fig. 3, Application(s) 226, User Interface Device Module 218; [0033]; [0044]; [0061]; [0062]).
Vongsouvanh further teaches a system that comprises a first device and a second device that are configured to perform the function(s)/step(s) above (see Fig. 1).
PNG
media_image1.png
630
468
media_image1.png
Greyscale
While Vongsouvanh discloses generating of the access token as described above, the difference between Vongsouvanh and current claim is a) that the device responsible for generating the access token is the computing system (i.e., remote system 118 in Vongsouvanh) not the first device, (i.e., computing device in Vongsouvanh); b) the access token is generated based on a device identifier corresponding to the second device; and c) wherein the transaction request causes the computing system to: (i) parse the device identifier corresponding to the second device from the device access token
Brugger, however, teaches the first device generating an access token (i.e., delegate ticket) that comprises a device identifier corresponding to the second device (i.e., delegate: client B)(see Fig. 6; [0037], the delegator may create a delegation ticket and the ticket includes who the delegate is) and wherein the transaction request causes the computing system to: (i) parse the device identifier corresponding to the second device from the device access token (see Fig. 6; [0037]; [0058]; [0072]).
It would have been obvious to one of ordinary skill in the art before the effective filing of instant claim to modify Vongsouvanh to substitute the technique of the first device in generating of the access token as taught by Brugger as the technique of generating of the access token in Vongsouvanh as the simple substitution of one known technique for another produces a predictable result rendering the claim obvious.
The applicant is reminded that the function(s) of the computing system do not move to differentiate from the method claim(s) as the function(s) are not part of the positively recited claim. Furthermore, the recited function(s) of the computing system do not move to differentiate the system claim as the system is directed to the first device and the second device. In other word, the computing system’s functions are outside the scope of the claimed system.
As per claims 4 and 14, Vongsouvanh/Brugger further teaches establishing, by the second device, a secure authorized session between the second device and the computing system (see Vongsouvanh: Fig. 1, communication pathway 124; [0075]).
As per claims 5, 7, 15, and 17, Vongsouvanh does not particularly teach retrievably storing, by the second device the device access token in a secure storage element of the second device and accessing, by the second device, the device access token from the secure storage element.
Brugger, however, teaches retrievably storing the device access token in a secure storage element and accessing the device access token from the secure storage element (see Fig. 3, delegation ticket storage; [0028] encryption; [0058]).
It would have been obvious to one of ordinary skill in the art before the effective filing of instant claim to include the teaching of retrievably storing the device access token in a secure storage as taught by Brugger to the access token and usage on the second device of the Vongsouvanh as the combination improves Vongsouvanh allowing reuse of the access token.
As per claims 8 and 18, Vongsouvanh/Brugger further teaches receiving, by the first device, an account restriction appliable to the second device or the second software application (see Vongsouvanh: [0026], a requested scope for the requested authorization; [0031]; [0034]).
As per claims 9 and 19, Vongsouvanh/Brugger further teaches generating the device access token to encode the account restriction applicable to the second device or the second software application (see Vongsouvanh: [0031], access token defines a specific scope)(Brugger: Fig. 6, restriction).
As per claims 10 and 20, Vongsouvanh/Brugger does not particularly teach determining, by the second device, that the transaction request does not violate the account restriction.
However, as Brugger generally teaches a device determining that the transaction request does not violate the account restriction (see Fig. 6) and Vongsouvanh also teaches use of application in a second device in requesting resources, it would have been obvious to one of ordinary skill in the art prior to the effective filing of the invention to modify Vongsouvanh for the second device to check or determine that the transaction request from the application does not violate the account restriction prior as the combination avoids needless sending of the request to the remote service.
Claim(s) 2-3 and 12-13 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Vongsouvanh” and “Brugger” as applied to claims 1 and 11 above, and further in view of US 20180191701 A1 (“Kong”).
Per claims 2 and 12, Vongsouvanh/Brugger does not particularly teach, however, Kong teaches receiving, by the first device, a selection of an account via the software application (see [0064], user can select one of multiple accounts … will identify or obtain the grant token for that account).
It would have been obvious to one of ordinary skill in the art before the effective filing of instant claim to include the technique of allowing a user to select an account to Vongsouvanh/Brugger in order to allow specific access, including account level access Vongsouvanh generally teaches use of token in specifying the scope of the resource and restriction.
As per claims 3 and 13, Vongsouvanh/Brugger does not particularly teach, however, Kong teaches generating, by the first device, the device access token further based on at least one of an identifier of an account or a user identifier of a user of the second device (see [0064], user can select one of multiple accounts … will identify or obtain the grant token for that account).
It would have been obvious to one of ordinary skill in the art before the effective filing of instant claim to include the technique of allowing a user to select an account to Vongsouvanh/Brugger in order to allow specific access, including account level access Vongsouvanh generally teaches use of token in specifying the scope of the resource and restriction.
Claim(s) 6 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Vongsouvanh” and “Brugger” as applied to claims 5 and 15 above, and further in view of US Patent Publication No. 20060112198 (“Kurokawa”).
As per claims 6 and 16, Vongsouvanh/Brugger does not particularly teach providing, by the second device, to the first device, and indication that the device access token has been stored in the secure storage element of the second device.
Kurokawa, however, teach providing by a second device to a first device an indication that the data (i.e., device status) has been stored in the storage element of the second device (see [0026], a first storage region for storing first device status information and sending the first device information stored in the first storage region to the management unit).
It would have been obvious to one of ordinary skill in the art before the effective filing of instant claim to include the technique of providing indication of status information to another device as taught by Kurokawa to Vongsouvanh/Brugger in order to keep the paired device(s) abreast of any known status events.
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-5, 7-15, and 17-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-3 and 5-6 of U.S. Patent No. 12,380,437. Although the claims at issue are not identical, they are not patentably distinct from each other because:
Per claim 1, ‘437 teaches a method comprising:
receiving, by a first device via a first software application executing on the first device, a request to enroll a second device in a server-to-device secure data exchange ecosystem, wherein the second device is locally paired to the first device (claim 1: receiving, by a first smart device via a first software application executing on the first smart device, a request to enroll a second smart device in a server-to-device secure data exchange ecosystem … wherein the second smart device is locally paired to the first smart device);
generating, by the first device, a device access token based on a device identifier corresponding to the second device (claim 1: generating, by the first smart device, a device access token based on (i) a device identifier corresponding to the second smart device);
providing, by the first device, the device access token to the second device (providing, by the first smart device, the device access token to the second smart device);
receiving, by the second device, a transaction request from a second software application executing on the second device (claim 1: receiving, by the second smart device, a transaction request from a second software application executing on the second smart device);
transmitting, by the second device, to a computing system, the device access token and the transaction request, wherein the transaction request causes the computing system to: (i) parse the device identifier corresponding to the second device from the device access token, and (ii) generate an electronic message for transmission to the second device (claim 1: transmitting, by the second smart device, to the computing system … the device access token and the transaction request, wherein the transaction request causes the computing system to: (i) parse the device identifier corresponding to the second smart device from the device access token, and (ii) generate an electronic message … receiving, by the second smart device, from the computing system … the electronic message responsive to the transaction request);
receiving, by the second device, from the computing system, the electronic message responsive to the transaction request (claim 1: receiving, by the second smart device, from the computing system … the electronic message responsive to the transaction request); and
providing, by the second device, to the second software application, a response to the transaction request based on the electronic message (claim 1: providing, by the second smart device, to the second software application, a response to the transaction request based on the electronic message).
Per other independent claim, claim 11, the claim is directed to a system comprising the first device and the second device of claim 1 that are configured to perform the step(s)/function(s) of the first device and the second device as recited in claim 1. As such, claim 11 is also rejected.
As per claims 2 and 12, ‘437 further discloses receiving, by the first device, a selection of an account via the first software application (claim 1: receiving, by the first smart device, a selection of a financial account held by the service provider; claim 2: wherein at least one of the request or the selection is received via the first software application executing on the first smart device).
As per claims 3 and 13, ‘437 further discloses generating, by the first device, the device access token further based on at least one of an identifier of an account or a user identifier of a user of the second device (claim 1: generating, by the first smart device, a device access token based on (i) a device identifier corresponding to the second smart device, (ii) a financial account identifier corresponding to the financial account, and (iii) a user identifier corresponding to a user of the second smart device).
As per claims 4 and 14, ‘437 further discloses establishing, by the second device, a secure authorized session between the second device and the computing system (claim 1: establishing, by the second smart device, a secure authorized session between the second smart device and the computing system).
As per claims 5 and 15, ‘437 further teaches retrievably storing, by the second device, the device access token in a secure storage element of the second device (claim 1: retrievably storing, by the second smart device, in a secure storage element of the second smart device, the device access token in association with an identifier of the first smart device).
As per claims 7 and 17, ‘437 further teaches accessing, by the second device, the device access token from the secure storage element (claim 1: retrievably storing, by the second smart device, in a secure storage element of the second smart device, the device access token … transmitting, by the second smart device, to the computing system, via the secure authorized session, the device access token and the transaction request)(retrievably storing by the second device the device access token in a secure storage element and transmitting the device access token by the second device clearly suggest that the second device access the device access token from the secure storage element in order to transmit the device access token to the computing system).
As per claims 8 and 18, ‘437 further teaches receiving, by the first device, an account restriction applicable to the second device or the second software application (claim 3: receiving, by the first smart device, an account restriction applicable to the second smart device or the second software application).
As per claims 9 and 19, while ‘437 further teaches receiving, by the first device, an account restriction applicable to the second device or the second software application (claim 3: receiving, by the first smart device, an account restriction applicable to the second smart device or the second software application), ‘437 claims do not particularly teach generating, by the first device, the device access token to encode the account restriction applicable to the second device or the second software application.
However, as ‘437 also teaches encoding of pertinent information in the device access token (claim 1: generating, by the first smart device, a device access token based on (i) a device identifier corresponding to the second smart device, (ii) a financial account identifier corresponding to the financial account, and (iii) a user identifier corresponding to a user of the second smart device … computing system to: (i) parse the device identifier corresponding to the second smart device from the device access token …) and that the account restriction is transmitted to the computing system (claim 6), it would have been obvious to one of ordinary skill in the art before the effective filing of instant claim to encode any known pertinent information, including the account restriction applicable to the second device or the second software application as disclosed in claim 3 as information encoded in the device access token in order to convey any pertinent information related to access to the computing system.
As per claims 10 and 20, ‘437 further discloses determining, by the second device, that the transaction request does not violate the account restriction (claim 5, applying, by the second smart device, the account restriction to the transaction request).
Claims 6 and 16 are rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1 of U.S. Patent No. 12,380,437 in view of US Patent Publication No. 20060112198 (“Kurokawa”).
Per claims 6 and 16, claim 1 of ‘437 teaches current claims 5 and 15. ‘437, however, does not particularly teach providing, by the second device, to the first device, and indication that the device access token has been stored in the secure storage element of the second device.
Kurokawa, however, teach providing by a second device to a first device an indication that the data (i.e., device status) has been stored in the storage element of the second device (see [0026], a first storage region for storing first device status information and sending the first device information stored in the first storage region to the management unit).
It would have been obvious to one of ordinary skill in the art before the effective filing of instant claim to include the technique of providing indication of status information to another device as taught by Kurokawa and apply to the storage event of the claim 1 of ‘437 in order to keep the paired device(s) abreast of any known status events.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US Patent Publication No. 20140365781 discloses a system and method that utilized delegated token in delegating access rights to a resource;
US Patent Publication No. 20140059565 discloses a method for providing settlement information in which a device provides settlement information to an application which is installed on the device includes executing a first application which is installed on the device, receiving settlement information from an external device via the executed first application, converting at least a part of the received settlement information, and providing the converted settlement information to a second application which is installed on the device in order to allow the second application to use the received settlement information;
US Patent No. 8,255,991 discloses a smartphone which allows a user to set permissions for application once it is installed via GUI;
US Patent Publication No. 20120291102 discloses a methods, systems, and apparatus, including computer programs encoded on a computer storage medium, for implementing permission-based administrative controls. The method includes receiving an administrator-defined pairing that identifies a permission and one or more applications, and receiving a request from a requesting application to perform one or more operations that are associated with the permission. The method also includes determining whether the requesting application is identified in the pairing, and selectively allowing the requesting application to perform the operations based on determining whether the requesting application is identified in the pairing;
US Patent No. 10469484 discloses a system according to the presently disclosed subject matter may include a means for receiving, by a client device associated with a first user account, a permission setting that allows third-party application to access a first-party notification interface that would otherwise be restricted to use only by first-party application on the client device. The system may include a means for receiving, from a third-party application operating on the client device, a first request for an access code that defines a level of access to the client device. The third-party application may be associated with a second user account at a third-party service. The system may include a means for providing, from the client device to the third-party application, the access code. The access code may be exchangeable for a refresh token and an access token provided by an authentication server. The system may include a means for receiving, from the third-party application, the access token and data from the third-party service to be included in a notification generated by the first-party notification interface. The system may include a means for presenting the notification on the client device.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to STEVEN S KIM whose telephone number is (571)270-5287. The examiner can normally be reached Monday -Friday: 7:00 - 3:30.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Patrick McAtee can be reached on 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 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.
/STEVEN S KIM/Primary Examiner, Art Unit 3698