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 .
Allowable Subject Matter
Claims 7-8, 14, and 20 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
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.
Claims 1-2, and 16-18 are rejected under 35 U.S.C. 103 as being unpatentable over urllib (urlib.parse, https://docs.python.org/3/library/urllib.parse.html 2009) (hereinafter urllib) in view of Lejin et al (US 2024/0205287) (hereinafter Lejin) .
As per claim 1, urllib teaches:
A method, comprising:
receiving a first request (urllib, pg 1—under BRI, a 1st request can be url), the first request including:
a search term for hostnames(urllib, pg 1—under BRI, a search term can be scheme://netloc);
a starting universal resource identifier (URI) associated with the hostnames (urllib, pg 1—under BRI, hostnames can be netloc and cwi ; and
a flag indicating use of members corresponding to the hostnames (urllib, pg 2—under BRI, use of members corresponding to the hostnames can be username);
obtaining the hostnames by searching a database based on the search term (urllib, pg 2—under BRI, searching a database based on the search term can be action of urllib.parse);
generating Hypertext Transfer Protocol (HTTP) requests based on the starting URI (urllib, pg 4—under BRI, generating Hypertext Transfer Protocol (HTTP) requests can be urllib.parse.urldefrag(url)), the obtained hostnames, and members corresponding to a respective obtained hostname (urllibs, pg 4);
Urllib does not expressly teach:
via a representational state transfer (REST) application programming interface (API);
transmitting the generated HTTP requests asynchronously to endpoints based on the REST API; and
receiving data from the endpoints in response to the first request indicating a GET command.
However, Lejin discloses:
via a representational state transfer (REST) application programming interface (API) (Lejin, [0019]);
transmitting the generated HTTP requests asynchronously to endpoints based on the REST API (Lejin, [0019]) ; and
receiving data from the endpoints in response to the first request indicating a GET command (Lejin, [0019]).
Both Lejin and urllib pertain to the art of web access.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to use Lejin’s method to use REST and GET because it is well-known in the art that REST (Representational State Transfer) architectural style offers unmatched scalability, flexibility, and simplicity for web services.
As per claim 2, urllib/Lejin teaches:
The method of claim 1 (see rejection on claim 1), wherein the first request further includes a first key associated with a first filter (Lejin, [0019]—under BRI, a first key associated with a first filter can be query params and its value), and wherein the method further comprises:
generating the HTTP requests based further on the first key and the first filter (Lejin, [0019]); and
in response to transmitting the generated http requests asynchronously to the endpoints, receiving, from a respective endpoint, a value corresponding to the first filter (Lejin, [0019]).
As per claim 16, see rejection on claim 1.
As per claim 17, see rejection on claim 1.
As per claim 18, see rejection on claim 2.
Claims 3-4, 10-12, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over urllib/Lejin as applied above, and further in view of Reed et al (US 2024/0007461) (hereinafter Reed)
As per claim 3, urllib/Lejin teaches:
The method of claim 1 (see rejection on claim 1).
urllib/Lejin does not expressly teach:
wherein the first request indicates a POST command , and wherein the first request further includes:
a partial URI associated with a target action; and
a second key indicating a data object with a parameter setting.
However, Reed discloses:
wherein the first request indicates a POST command (Reed, [0028]), and wherein the first request further includes:
a partial URI associated with a target action(Reed [0028]); and
a second key indicating a data object with a parameter setting(Reed,[0028]).
Both Reed and urllib/Lejin pertain to the art of web access.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to use Reed’s method to use REST and POST because it is well-known in the art that the primary benefit of the POST command in REST is its ability to submit data to the server for processing, making it the standard method for creating new resources (like a new user or order) where the server generates the unique URI/ID, or for executing custom, non-CRUD operations
As per claim 4, urllib/Lejin/Reed teaches:
The method of claim 3 (see rejection on claim 3), further comprising:
generating the HTTP requests based further on:
the partial URI associated with the target action; and the second key indicating the data object with the parameter setting (Reed, [0028]); and
in response to transmitting the generated http requests asynchronously to the endpoints, causing the target action to be performed at a respective endpoint based on the parameter setting Reed, [0028]).
As per claim 10, see rejection on claims 2 and 3.
As per claim 11, see rejection on claim 2.
As per claim 12, see rejection on claim 4.
As per claim 19, see rejection on claims 3 and 4.
Claims 5-6 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over urllib/Lejin/Reed as applied above, and further in view of Le et al (US 2009/0006614) (hereinafter Le) .
As per claim 5, urllib/Lejin/Reed teaches:
The method of claim 4 (See rejection on claim 4).
urllib/Lejin/Reed does not expressly teach:
further comprising:
receiving, from the respective endpoint, a status associated with the target action which is performed at the respective endpoint based on the parameter setting.
However, Le discloses:
further comprising:
receiving, from the respective endpoint, a status associated with the target action which is performed at the respective endpoint based on the parameter setting (Le, [0042]).
Both Le and urllib/Lejin/Reed pertain to the art of web access.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to use Le’s method to receive a REST status because it is well-known in the art that this ensures the system remains stateless and decouples the client from server internals.
As per claim 6, urllib/Lejin/Reed/Le teaches:
The method of claim 5 (See rejection on claim 5), wherein the first request further includes a flag requesting a return of content in response to the target action being performed, and wherein the received status indicates the returned content (Le, [0042]—under BRI, a flag can be (c) verify keyword: keyword to verify a successful transaction; and/or (d) error keyword: keyword to verify an unsuccessful transaction.
As per claim 13, see rejection on claim 5.
Claims 9 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over urllib/Lejin as applied to claim 1 above, and further in view of Helipern et al (US 2018/0054493) (hereinafter Helipern).
As per claim 9, urllib/Lejin teaches:
The method of claim 1 (see rejection on claim 1),
Urllib/Lejin does not expressly teach:
wherein obtaining the hostnames is based further on matching credential information associated with the first request with credential information associated with a respective expanded hostname.
However, Heilpern discloses:
wherein obtaining the hostnames is based further on matching credential information associated with the first request with credential information associated with a respective expanded hostname (Heilpern, [0054]).
Both Helipern and urllib/Lejin pertain to the art of web access.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to use Helipern’s method to match credential information because it is well-known in the art that in REST architecture, "matching credentials" helps validate a client's identity against server-side records to enforce security.
As per claim 15, see rejection on claim 9.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. US 9292613 teaches a method for generating universal resource indicator.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHARLIE SUN whose telephone number is (571)270-5100. The examiner can normally be reached 9AM-5PM.
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, Pierre Vital can be reached at (571) 272-4215. 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.
/CHARLIE SUN/Primary Examiner, Art Unit 2198
Prosecution Insights