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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office Action has been withdrawn pursuant to 37 CFR 1.114. Applicant’s submission filed on 05/20/2026 has been entered.
Response to Amendments
This communication is in response to the amendments filed on 23 April 2026:
Claims 1 and 3-5 are amended.
Claim 2 is canceled.
Claims 1 and 3-6 are pending.
Response to Arguments
In response to Applicant’s remarks filed on 23 April 2026:
a. Applicant’s arguments regarding the 35 U.S.C. 101 rejection on claim 4 has been fully considered and is deemed fully persuasive in view of the amendments. The 35 U.S.C. 101 rejection on claim 4 has been withdrawn.
b. Applicant’s arguments that neither Robinson nor Matsuda teach “wherein the resource holder node is a user node that owns a Social Networking Service (SNS) account of a client corresponding to the client user node” has been fully considered but is deemed moot in view of the new grounds of rejection presented in this Office Action.
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 and 3-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), in further view of Schmid et al. (U.S. PGPub. 2016/0285816), hereinafter Schmid.
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]).
Robinson as modified by Matsuda do not teach the following limitation(s) as taught by Schmid: wherein the resource holder node is a user node that owns a Social Networking Service (SNS) account of a client corresponding to the client user node (Schmid, Paragraph [0059], see “…a user may be an individual (human user), an entity (e.g., an enterprise, business, or third-party application), or a group…when a user registers for an account with the social-networking service, the social-networking service may create a user node 202 corresponding to the user, and store the user node 202 in one or more data stores…”, which is analogous to a user node that owns an SNS account of a client) (Schmid, Paragraph [0127], see “…The messaging package 820 may comprise a user message 830 from the user of the client device 120 directed to a business entity as identified by a business page for the business entity with the social networking service 170. The message may form a query, request, or directive to the business, such as regarding the products and services of the business”, which is analogous to the client user node (i.e., user message) requesting services from a resource holder node (i.e., user node that owns the SNS account)).
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 resource holder node being a user node that owns a social networking service account of a client, disclosed of Schmid.
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 resource holder node being a user node that owns a social networking service account of a client. This allows for better security management by centralizing system management and eliminating third-party intermediaries by having the resource holder node own an SNS account of the client. Schmid is deemed as analogous art due to the art disclosing techniques of the resource holder node being a user node that owns a social networking service account of a client (Schmid, Paragraph [0059]).
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 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 “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”, 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) by the resource holder node (second 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 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]).
Robinson as modified by Matsuda do not teach the following limitation(s) as taught by Schmid: wherein the resource holder node is a user node that owns a Social Networking Service (SNS) account of a client corresponding to the client user node (Schmid, Paragraph [0059], see “…a user may be an individual (human user), an entity (e.g., an enterprise, business, or third-party application), or a group…when a user registers for an account with the social-networking service, the social-networking service may create a user node 202 corresponding to the user, and store the user node 202 in one or more data stores…”, which is analogous to a user node that owns an SNS account of a client) (Schmid, Paragraph [0127], see “…The messaging package 820 may comprise a user message 830 from the user of the client device 120 directed to a business entity as identified by a business page for the business entity with the social networking service 170. The message may form a query, request, or directive to the business, such as regarding the products and services of the business”, which is analogous to the client user node (i.e., user message) requesting services from a resource holder node (i.e., user node that owns the SNS account)).
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 resource holder node being a user node that owns a social networking service account of a client, disclosed of Schmid.
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 resource holder node being a user node that owns a social networking service account of a client. This allows for better security management by centralizing system management and eliminating third-party intermediaries by having the resource holder node own an SNS account of the client. Schmid is deemed as analogous art due to the art disclosing techniques of the resource holder node being a user node that owns a social networking service account of a client (Schmid, Paragraph [0059]).
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 a client user 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 server” is being read as an authorization server);
wherein authorization of the resource holder node is required for invocation of the API of the client user node (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”, which is being read as the authorization of the resource holder node being required for invocation of the API of the client user node); and
wherein the resource holder node is identifiable 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);
a processor that verifies the authorization request and authorizes the client user node (Robinson, Fig. 2, see “209”, which upon receipt of 209, first server 101 performs an authentication 109 of said first user (client user node)); and
a transmitter that transmits, to the authorization server, information indicating that the invocation of the API of the client user node 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 client user node is authorized),
Robinson does not teach the following limitation(s) as taught by Matsuda: wherein the information indicating that the invocation of the API of the client user node is authorized allows the authorization server to issue an access token for 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”, which is analogous to the authorization server issuing an access token for the client user node based on verifying the request (i.e., indicating that the invocation 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]).
Robinson as modified by Matsuda do not teach the following limitation(s) as taught by Schmid: wherein the resource holder node is a user node that owns a Social Networking Service (SNS) account of a client corresponding to the client user node (Schmid, Paragraph [0059], see “…a user may be an individual (human user), an entity (e.g., an enterprise, business, or third-party application), or a group…when a user registers for an account with the social-networking service, the social-networking service may create a user node 202 corresponding to the user, and store the user node 202 in one or more data stores…”, which is analogous to a user node that owns an SNS account of a client) (Schmid, Paragraph [0127], see “…The messaging package 820 may comprise a user message 830 from the user of the client device 120 directed to a business entity as identified by a business page for the business entity with the social networking service 170. The message may form a query, request, or directive to the business, such as regarding the products and services of the business”, which is analogous to the client user node (i.e., user message) requesting services from a resource holder node (i.e., user node that owns the SNS account)).
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 resource holder node being a user node that owns a social networking service account of a client, disclosed of Schmid.
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 resource holder node being a user node that owns a social networking service account of a client. This allows for better security management by centralizing system management and eliminating third-party intermediaries by having the resource holder node own an SNS account of the client. Schmid is deemed as analogous art due to the art disclosing techniques of the resource holder node being a user node that owns a social networking service account of a client (Schmid, Paragraph [0059]).
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]).
Robinson as modified by Matsuda do not teach the following limitation(s) as taught by Schmid: wherein the resource holder node is a user node that owns a Social Networking Service (SNS) account of a client corresponding to the client user node (Schmid, Paragraph [0059], see “…a user may be an individual (human user), an entity (e.g., an enterprise, business, or third-party application), or a group…when a user registers for an account with the social-networking service, the social-networking service may create a user node 202 corresponding to the user, and store the user node 202 in one or more data stores…”, which is analogous to a user node that owns an SNS account of a client) (Schmid, Paragraph [0127], see “…The messaging package 820 may comprise a user message 830 from the user of the client device 120 directed to a business entity as identified by a business page for the business entity with the social networking service 170. The message may form a query, request, or directive to the business, such as regarding the products and services of the business”, which is analogous to the client user node (i.e., user message) requesting services from a resource holder node (i.e., user node that owns the SNS account)).
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 resource holder node being a user node that owns a social networking service account of a client, disclosed of Schmid.
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 resource holder node being a user node that owns a social networking service account of a client. This allows for better security management by centralizing system management and eliminating third-party intermediaries by having the resource holder node own an SNS account of the client. Schmid is deemed as analogous art due to the art disclosing techniques of the resource holder node being a user node that owns a social networking service account of a client (Schmid, Paragraph [0059]).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Robinson, in view of Matsuda, in further view of Schmid, in further view of Tin et al. (U.S. PGPub. 2020/0145421), hereinafter Tin.
Regarding claim 6, Robinson as modified by Matsuda and further modified by Schmid 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, techniques disclosed of Matsuda, and techniques disclosed of Schmid, 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
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
Prosecution Insights