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 .
Response to Amendments
This communication is in response to the amendments filed on 2 October 2025:
Claims 1 and 3-5 are amended.
Claim 2 is canceled.
Claim 6 is added.
Claims 1 and 3-6 are pending.
Response to Arguments
In response to Applicant’s remarks filed on 2 October 2025:
a. Applicant’s arguments regarding the 35 U.S.C. 101 rejection on claims 1-2 and 4 have been fully considered and are deemed partially persuasive and partially not-persuasive. The 35 U.S.C. 101 rejection on claims 1-2 have been withdrawn. Applicant’s attention is directed to the updated 35 U.S.C. 101 rejection on claim 4 below.
b. Applicant’s arguments that none of the cited references disclose or suggest a structure that can teach “resource holder node,” which is a term of art has been fully considered but is deemed not-persuasive. Applicant’s attention is directed to Applicant’s specification, which defines a resource holder node to be another user, a user that owns an SNS account or a terminal owned by the user. Therefore, the updated rejection by the Examiner interprets the resource holder node to be similar to a second user or second user device. Applicant’s attention is further directed to the 35 U.S.C. 103 rejection set forth below.
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 4 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Regarding claim 4, the claim recites the abstract idea of organizing human activity. For example
limitations:
a receiver that receives, from an authorization server, information…
a processor that verifies the authorization request…
a transmitter that transmits, to the authorization server, information…
see MPEP 2106.04.
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because the claim only includes well-understood, routine, conventional computer functions in addition to the cited abstract idea and does not recite an inventive concept. see MPEP 2106.05(d)
For example the courts have recognized the following computer functions as well understood, routine, and conventional.
Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014) ("Unlike the claims in Ultramercial, the claims at issue here specify how interactions with the Internet are manipulated to yield a desired result‐‐a result that overrides the routine and conventional sequence of events ordinarily triggered by the click of a hyperlink." (emphasis added));
Furthermore, this judicial exception is not integrated into a practical application. In particular, the claim recites two additional elements – a resource holder node and an authorization server. The resource holder node and authorization server are recited at a high-level of generality such that it amounts to no more than using a generic (computer) component. Accordingly, the additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
MPEP section 2106.05 I is titled THE SEARCH FOR AN INVENTIVE CONCEPT; here, the MPEP makes it clear that patentability does not rest on novelty or non-obviousness alone, but that there must be an inventive concept.
Section A provides six examples of what may constitute an inventive concept; applicants claim does not include limitations corresponding to any of the items i-vi.
Section A also provides 4 examples of what may not constitute an inventive concept; similarly, applicant’s claim does not include limitations that amount to enough to qualify as significantly more than the abstract idea itself because the limitations in addition to the abstract ideas amount to insignificant extra-solution activity, a general linking the use of the judicial exception to a particular technological environment or field of use, and well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception.
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.
Claims 1-5 are rejected under 35 U.S.C. 103 as being unpatentable over Robinson et al. (U.S. PGPub. 2014/0082705), hereinafter Robinson, in view of Matsuda (U.S. PGPub. 2015/0193600).
Regarding claim 1, Robinson teaches An authorization server (Robinson, Paragraph [0026],
see “Said first server comprises authentication means adapted to authenticate first credentials…”, where “first server” is being read as an authorization server), comprising:
a receiver that receives, from a client user node, an authorization request for
invocation of an Application Programming Interface (API) which requires authorization from a resource holder node (Robinson, Paragraph [0051], see “…said second client 104 is
adapted to prompt said second user HU to authorize said access request by said first user EU to said function”, where “first user” is being read as the client user node, where “second user” is being read as comprising the resource holder node, due to the Applicant’s specification defining resource holder node as being a second user or second user terminal) (Robinson, Paragraph [0052], see “Upon successful authentication 209, or optionally upon receipt of a positive response in message 211, said first server 101 is adapted to send a message 212, Request, to said second server 102. Said message 212 is for example a request to access to a function via said interface API”);
a processor that identifies the resource holder node based on the authorization
request (Robinson, Paragraph [0007], see “…This way, said first server receives information required to authenticate said first user, identifies said second user and the request of the first user, and sends information required for authentication on said second server to the second server”, where the resource holder node (second user) is identified based on the request); and
a transmitter that transmits, to the resource holder node, information indicating
that the authorization request has been received from the client user node (Robinson, Fig. 2, see “210”, which sends a message from the first server to the second user (resource holder node), which includes information indicating that the authorization request has been received from the (client user node) first user and the first user is authenticated),
wherein:
the receiver receives, from the resource holder node, information indicating that the authorization has been made for the invocation of the API of the client user node (Robinson, Fig. 2, see “211”, which depicts the second user (resource holder node) sending information indicating that the authorization has been made for the invocation of the API (access to the function) of the first user (client user node));
Robinson does not teach the following limitation(s) as taught by Matsuda: the processor issues an access token, based on the authorization of the resource holder node (Matsuda, Paragraph [0014], see “…verify the authorization request and issue an access token to the client when the verification is successful”); and
the transmitter transmits the access token to the client user node (Matsuda, Paragraph [0014], see “…verify the authorization request and issue an access token to the client when the verification is successful”, when the access token is issued, it is stored and used by the user’s application for subsequent resource requests, therefore, it is successfully received by the first user).
Assuming purely arguendo that Applicant does not believe Robinson successfully teaches a request for invocation of an Application Programming Interface (API), Applicant’s attention is directed to Matsuda, Paragraph [0044], see “…The API 313 executes processing required by a function provided by the resource server, generates a response to an API invocation request from a client, and returns the response to the client…”).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the techniques disclosed of Robinson, by implementing techniques of issuing an access token for access to invoking the API, disclosed of Matsuda.
One of ordinary skill in the art would have been motivated to make this modification in order to implement techniques for network node communication, comprising of issuing an access token for access to invoking the API. This allows for better security management by requesting to invoke an API through issuance of an access token, allowing for a more secure interaction between programs. Matsuda is deemed as analogous art due to the art disclosing techniques of issuing an access token for access to invoking the API (Matsuda, Paragraph [0014]).
Regarding claim 3, Robinson teaches A client user node, comprising:
a transmitter that transmits, to an authorization server, an authorization request for invocation of an Application Programming Interface (API) which requires authorization from another user (Robinson, Paragraph [0051], see “…said second client 104 is adapted to prompt said second user HU to authorize said access request by said first user EU to said function”) (Robinson, Paragraph [0052], see “Upon successful authentication 209, or optionally upon receipt of a positive response in message 211, said first server 101 is adapted to send a message 212, Request, to said second server 102. Said message 212 is for example a request to access to a function via said interface API”, where “first server” is being read as the authorization server);
a receiver that receives, from the authorization server, information Robinson, Fig. 2, see “211”, which depicts sending information indicating that the authorization has been made for the invocation of the API (access to the function) of the first user);
Robinson does not teach the following limitation(s) as taught by Matsuda: an access token (Matsuda, Paragraph [0014], see “…verify the authorization request and issue an access token to the client when the verification is successful”); and
a processor that invokes, using the access token, the API which requires the authorization from the other user (Matsuda, Paragraph [0066], see “…The issued access token indicates that the access right to access to the resource (in this example, API invocation or the provision of a service via the API) has been delegated from the user of the resource server to the client that uses the access token”).
Assuming purely arguendo that Applicant does not believe Robinson successfully teaches a request for invocation of an Application Programming Interface (API), Applicant’s attention is directed to Matsuda, Paragraph [0044], see “…The API 313 executes processing required by a function provided by the resource server, generates a response to an API invocation request from a client, and returns the response to the client…”).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the techniques disclosed of Robinson, by implementing techniques of issuing an access token for access to invoking the API, disclosed of Matsuda.
One of ordinary skill in the art would have been motivated to make this modification in order to implement techniques for network node communication, comprising of issuing an access token for access to invoking the API. This allows for better security management by requesting to invoke an API through issuance of an access token, allowing for a more secure interaction between programs. Matsuda is deemed as analogous art due to the art disclosing techniques of issuing an access token for access to invoking the API (Matsuda, Paragraph [0014]).
Regarding claim 4, Robinson teaches A resource holder node (Robinson, Fig. 1, see “104”, which depicts a second client, which is being read as comprising the resource holder node) comprising:
a receiver that receives, from an authorization server, information indicating that an authorization request for invocation of an Application Programming Interface (API) has been received from another user (Robinson, Paragraph [0051], see “…said second client 104 is adapted to prompt said second user HU to authorize said access request by said first user EU to said function”) (Robinson, Paragraph [0052], see “Upon successful authentication 209, or optionally upon receipt of a positive response in message 211, said first server 101 is adapted to send a message 212, Request, to said second server 102. Said message 212 is for example a request to access to a function via said interface API”, where “first server” is being read as an authorization server);
a processor that verifies the authorization request and authorizes the other user (Robinson, Fig. 2, see “209”, which upon receipt of 209, first server 101 performs an authentication 109 of said first user); and
a transmitter that transmits, to the authorization server, information indicating that the invocation of the API of the other user is authorized (Robinson, Fig. 2, see “210” and “211”, where “211” may be an authorization result with information indicating that the invocation of the API of the other user is authorized).
Assuming purely arguendo that Applicant does not believe Robinson successfully teaches a request for invocation of an Application Programming Interface (API), Applicant’s attention is directed to Matsuda, Paragraph [0044], see “…The API 313 executes processing required by a function provided by the resource server, generates a response to an API invocation request from a client, and returns the response to the client…”).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the techniques disclosed of Robinson, by implementing techniques of requesting for invocation of an API, disclosed of Matsuda.
One of ordinary skill in the art would have been motivated to make this modification in order to implement techniques for network node communication, comprising of requesting for invocation of an API. This allows for better security management by requesting to invoke an API through issuance of an access token, allowing for a more secure interaction between programs. Matsuda is deemed as analogous art due to the art disclosing techniques of requesting for invocation of an API (Matsuda, Paragraph [0044]).
Regarding claim 5, Robinson teaches A communication method, comprising:
indicating to an authorization server, by a client user node, an authorization request for invocation of an Application Programming Interface (API) which requires authorization from a resource holder node (Robinson, Paragraph [0051], see “…said second client 104 is adapted to prompt said second user HU to authorize said access request by said first user EU to said function”) (Robinson, Paragraph [0052], see “Upon successful authentication 209, or optionally upon receipt of a positive response in message 211, said first server 101 is adapted to send a message 212, Request, to said second server 102. Said message 212 is for example a request to access to a function via said interface API”, where “first user” is being read as a client user node, where “second client” or “second user” is being read as comprising the resource holder node);
identifying, by the authorization server, the resource holder node based on the authorization request Robinson, Paragraph [0007], see “…This way, said first server receives information required to authenticate said first user, identifies said second user and the request of the first user, and sends information required for authentication on said second server to the second server”, where the second user is identified based on the request);
transmitting to the resource holder node, by the authorization server, information indicating that the authorization request has been received from the client user node (Robinson, Fig. 2, see “210”, which sends a message from the first server to the second user, which includes information indicating that the authorization request has been received from the first user and the first user is authenticated);
verifying, by the resource holder node, the authorization request and authorizing, by the resource holder node, the client user node (Robinson, Fig. 2, see “210” and “211”, where “210” is a message for example a request for authorization of access to said functions, which is verified by the second user (resource holder node));
transmitting to the authorization server, by the resource holder node, information indicating that the authorization has been made for the invocation of the API of the client user node (Robinson, Fig. 2, see “210” and “211”, where “211” may be an authorization result with information indicating that the invocation of the API of the other user is authorized);
Robinson does not teach the following limitation(s) as taught by Matsuda: issuing an access token, by the authorization server, based on the authorization of the resource holder node (Matsuda, Paragraph [0014], see “…verify the authorization request and issue an access token to the client when the verification is successful”);
transmitting the access token to the client user node, by the authorization server (Matsuda, Paragraph [0014], see “…verify the authorization request and issue an access token to the client when the verification is successful”, when the access token is issued, it is stored and used by the user’s application for subsequent resource requests, therefore, it is successfully received by the first user); and
invoking, by the client user node using the access token, the API which requires the authorization from the resource holder node (Matsuda, Paragraph [0066], see “…The issued access token indicates that the access right to access to the resource (in this example, API invocation or the provision of a service via the API) has been delegated from the user of the resource server to the client that uses the access token”).
Assuming purely arguendo that Applicant does not believe Robinson successfully teaches a request for invocation of an Application Programming Interface (API), Applicant’s attention is directed to Matsuda, Paragraph [0044], see “…The API 313 executes processing required by a function provided by the resource server, generates a response to an API invocation request from a client, and returns the response to the client…”).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the techniques disclosed of Robinson, by implementing techniques of issuing an access token for access to invoking the API, disclosed of Matsuda.
One of ordinary skill in the art would have been motivated to make this modification in order to implement techniques for network node communication, comprising of issuing an access token for access to invoking the API. This allows for better security management by requesting to invoke an API through issuance of an access token, allowing for a more secure interaction between programs. Matsuda is deemed as analogous art due to the art disclosing techniques of issuing an access token for access to invoking the API (Matsuda, Paragraph [0014]).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Robinson, in view of Matsuda, in further view of Tin et al. (U.S. PGPub. 2020/0145421), hereinafter Tin.
Regarding claim 6, Robinson as modified by Matsuda do not teach the following limitation(s) as
taught by Tin: The communication method according to claim 5, wherein the API is invoked through an application managed by the authorization server (Tin, Paragraph [0018], see “…one or more of the APIs 131-13M may be invoked by the applications 121-12N to implement the specified functions according to functions/requirements/permissions…the authentication server 110 further manages the permissions of multiple applications for invoking APIs”).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the techniques disclosed of Robinson, and techniques disclosed of Matsuda, by implementing techniques of the API being invoked through an application managed by the authorization server, disclosed of Tin.
One of ordinary skill in the art would have been motivated to make this modification in order to implement techniques for network node communication, comprising of the API being invoked through an application managed by the authorization server. This allows for better security management and granular access control by having the APIs invoke applications managed by an authorization server, allowing for policies and permission to be applied uniformly across different applications/services. Tin is deemed as analogous art due to the art disclosing techniques of the API being invoked through an application managed by the authorization server (Tin, Paragraph [0018]).
Conclusion
Applicant’s amendment necessitated the new ground(s) 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RODMAN ALEXANDER MAHMOUDI whose telephone number is (571)272-8747. The examiner can normally be reached on M-F 11:00am – 7:00pm.
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, Philip Chea can be reached on (571) 272-3951. 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 the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/RODMAN ALEXANDER MAHMOUDI/Examiner, Art Unit 2499