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 AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination (RCE) 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 08/04/2025 has been entered.
Status of Claims
This communication is a Non-Final Office action in response to RCE filed on 08/04/2025. Claims 1, 3, 4, 7, 9-12 have been amended. Claims 2 and 8 have been canceled. Therefore, claims 1, 3-7, and 9-12 are currently pending and have been addressed below.
Response to Amendment
Applicant has amended claim 1 to overcome the claim objection. Examiner withdraws the claim objection for claim 1.
Applicant has amended claims 1 and 7 to overcome the 112(a) rejections. Therefore, Examiner withdraws the 112(a) rejections.
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, 3-7 and 9-12 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to a judicial exception without a practical application and significantly more.
Step 1: Identifying Statutory Categories
When considering subject matter eligibility under 35 U.S.C. § 101, it must be determined whether the claims are directed to one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter (i.e., Step 1). In the instant case, claims 1, 3-6 are directed to a method (i.e., a process). Claims 7 and 9-12 are directed to a system (i.e. a machine). Thus, each of these claims falls within one of the four statutory categories. Nevertheless, the claims fall within the judicial exception of an abstract idea.
Step 2A: Prong One: Abstract Ideas
Claims 1, 3-7 and 9-12 are rejected under 35 U.S.C. 101 because the claimed invention recites an abstract idea. Independent claims 1 and 7 are analogous. Claim 7 recites: A system for providing a portable curriculum vitae, which comprises: first client information, a second client information, third client information, and curriculum vitae items data, the first client information, the second client information and the third client information each including a permission data of a corresponding client, the curriculum vitae items data containing a first curriculum vitae item to the internal training and a second curriculum vitae item to the external training;the curriculum vitae items data identifies the first client information based on client information received; receives a curriculum vitae, the curriculum vitae including a form containing a plurality of records associated with the first client information and curriculum vitae items data for each of the plurality of records; displays the received curriculum vitae; receives a user input on the plurality of records to update the curriculum vitae items data in the form; transmits a first completion request directed to the internal training and the updated curriculum vitae items data; after receiving the transmitted first completion request and the updated curriculum vitae items data determines whether the permission data in the second client information is superior than the permission data in the first client information; when determines that the permission data in the second client information is superior than the permission data in the first client information, notifies and transmits a first checklist form including a first checking and signing field according to the updated curriculum vitae items data; displays the first checklist form; receives a first seal entered to audit and sign the first curriculum vitae item in the first checklist form; receives and stores the audited first checklist form transmitted; after receiving the audited first checklist form transmits a second completion request, receives the second completion request notifies and transmits a second checklist form including a second checking and signing field according to the updated curriculum vitae items data; receives a second seal entered by the third user to audit and sign the second curriculum vitae item in the second checklist form; receives and stores the audited second checklist form.
The limitations as drafted, is a process that, under its broadest reasonable interpretation, falls under the abstract groupings of:
Certain methods of organizing human activity (commercial or legal interactions (including advertising, marketing or sales activities or behaviors; business relations; (managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions)). As the claims discuss providing a portable curriculum vitae, including curriculum vitae items containing a first curriculum vitae item to the internal training and a second curriculum vitae item to the external training; checklist forms including a checking and signing field and receiving a first and a second seal entered to audit and sign the first curriculum vitae item by a superior, which is one of certain methods of organizing human activity.
Mental Processes (concepts performed in the human mind (including an observation, evaluation, judgement, opinion (independent claims 1 and 7 recite for example, “providing a portable curriculum vitae”; “identifies the first client information based on client information received”; “receives a curriculum vitae, the curriculum vitae including a form containing a plurality of records associated with the first client information”; “displays the received curriculum vitae; receives a user input on the plurality of records to update the curriculum vitae items data in the form”; “transmits a first completion request directed to the internal training and the updated curriculum vitae items data”; “receiving the transmitted first completion request and the updated curriculum vitae items data determines whether the permission data in the second client information is superior than the permission data in the first client information”; “when determines that the permission data in the second client information is superior than the permission data in the first client information”, “notifies and transmits a first checklist form including a first checking and signing field according to the updated curriculum vitae items data”; “displays the first checklist form; receives a first seal entered to audit and sign the first curriculum vitae item in the first checklist form”; “receives and stores the audited first checklist form transmitted”; “after receiving the audited first checklist form transmits a second completion request, receives the second completion request and transmits a second checklist form including a second checking and signing field according to the updated curriculum vitae items data”; “receives a second seal entered by the third user to audit and sign the second curriculum vitae item in the second checklist form”; “receives and stores the audited second checklist form.”) Concepts performed in the human mind as mental processes because the steps of identifying, providing, receiving, determining, transmitting, checking and signing, and analyzing data mimic human thought processes of observation, evaluation, judgement and opinion, perhaps with paper and pencil, where data interpretation is perceptible in the human mind. See In re TLI Commc’ns LLCPatentLitig., 823 F.3d 607, 611 (Fed. Cir. 2016); FairWarning IP, LLC v. Iatric Sys., Inc., 839 F.3d 1089, 1093-94 (Fed. Cir. 2016)).
Dependent claims add additional limitations, for example: (claims 3 and 9) the first client further records a time length, a work proceeding, a completion status, or any combination thereof in connection with all the work items to the cloud server at the same time; (claims 5 and 11) wherein, the curriculum vitae data includes at least one work item record, at least one academic record, one educational level, one major subject, one industry sector of former jobs, one title of former jobs, one personal expertise, one professional certification, one language ability or a combination of two or more conditions; (claim 6) wherein, the curriculum vitae items data is transmitted and accessed between the first client; the second client and the third client audit and sign the curriculum vitae item data; (claim 12) wherein, the curriculum vitae items data is transmitted and accessed between the first client The second client and the third client audit and sign the first curriculum vitae item and the second curriculum vitae item. The curriculum vitae items data, the first seal and the second seal are transmitted, but these only serve to further limit the abstract idea. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation of methods of mental processes and organizing human activity but for the recitation of generic computer components, the claims recite an abstract idea.
Step 2A: Prong Two
This judicial exception is not integrated into a practical application because the claims merely describe how to generally “apply” the abstract idea. In particular, the claims only recite the additional elements – (claim 1) device(s); server; network; cloud server; processing unit; data storage unit; curriculum vitae interface; digital seal(s); (claims 4 and 10) a public key infrastructure (claims 6 and 12); block chain (claim 7); cloud server; data storage unit; device(s); network. These additional elements are recited at a high-level of generality such that it amounts to no more than mere instructions to apply the exception using generic computer components. Simply implementing the abstract idea on generic computer components is not a practical application of the abstract idea, as it adds the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea, as discussed in MPEP 2106.05(f). The limitations generally link the abstract idea to a particular technological environment or field of use (such as computing or blockchain technology, see MPEP 2106.05(h)). Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely provide generic computer implementation and do not impose a meaningful limit to integrate the abstract idea into a practical application.
Step 2B:
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to discussion of integration of the abstract idea into a practical application, the additional elements amount to no more than mere instructions to apply an exception and generally link the abstract idea to a particular technological environment or field of use. Furthermore, claims 1, 3-7 and 9-12 have been fully analyzed to determine whether there are additional elements recited that amount to significantly more than the abstract idea. The limitations fail to include an improvement to another technology or technical field, an improvement to the functioning of the computer itself, or meaningful limitations beyond generally linking the use of the abstract idea to a particular technological environment. Thus, nothing in the claim adds significantly more to the abstract idea. Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely provide conventional computer implementation. The claims are ineligible. Therefore, since there are no limitations in the claim that transform the exception into a patent eligible application such that the claim amounts to significantly more than the exception itself, the claims are rejected under 35 USC 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either 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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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 non-obviousness.
Claims 1, 3-7 and 9-12 are rejected under 35 U.S.C. 103 as being unpatentable over Mercury et al. (US 2019/0087781 A1), hereinafter “Mercury”, over Apps (WO 2013/170346 A1), hereinafter “Apps”.
Regarding Claim 1, Mercury teaches A method for providing portable curriculum vitae, which comprises: (See at least Mercury, para 0029-0030, teaches creating and managing a blockchain record of issued badges; Mercury, para 0198, storing, maintaining, and serving requests for “resumes”; A user's resume may include the collection of badges that user has earned... badge portfolio may include education-based and skills-based badges, professional credentials, personality badges, DNA-based badges, health-based or fitness-based badges, etc... a user's resume also may include data (or links to data) including the badge details (e.g., badge description, skills, owner, etc.) and issuance details (e.g., issue date, issuer, test center and type of testing process (e.g., written testing, live simulation, augmented reality or virtual reality simulation, etc.), issue location, etc.). Certain user badge resumes also may include current status of the user's badge portfolio, along with evidence data files and/or user authentication data identifying the user authentication techniques/processes associated with the earned badge.);
a first device operated by a first client, a second device operated by a second client, a third device operated by a third client, and a server connected to each other via a network, the cloud server having an account processing unit and a data storage unit storing client information including first client information, second client information, third client information and curriculum vitae items data, the first client information, the second client information and the third client information each including a permission data of a corresponding client, the curriculum vitae items data including a first curriculum vitae item directed to an internal training and a second curriculum vitae item directed to an external training; (See at least Mercury, Figure 2, teaches multiple client devices in communications network, element 210 teaches a datastore; para 0066, teaches components may include one or more dedicated web servers and network hardware in a datacenter or a cloud infrastructure; training is taught throughout Mercury, see at least Mercury, para 0002, 0058-0059, 0105-0107, 0166, teaches training programs; permission data is throughout, see at least Mercury, para 0155, verifying the requestor's identity or role and comparing to an access control list or other permissions data; Further, Mercury, para 0074 and 0078, accounts data store for individual end users, supervisors, administrator users, and entities such as companies or educational institutions; certain users may have supervisory access over one or more users);
the method comprising:
identifying, by the cloud server, the first client information based on client information received by the first device; (See at least Mercury, para 0063, devices on a web-based or cloud-based service; Mercury, para 0073, user profile data store may include information relating to the end users);
receiving, by the first device, a curriculum vitae interface transmitted from the cloud server, the curriculum vitae interface including a form containing a plurality of records associated with the first client information and curriculum vitae items data for each of the plurality of records; (Interfaces are taught throughout Mercury, see at least para 0033, FIGS. 30A and 30B are screenshots depicting example of different user interface views for displaying a user's badge resume; Mercury, para 0008, teaches a computing environment for generating, managing, and tracking digital credential templates (Examiner notes form) and digital credentials; Further, Mercury, para 0105-0106, teaches digital credential templates may include templates for various technology certifications, licensure exams, professional tests, training course completion certificates, and the like. In contrast to a digital credential template, a digital credential (or digital badge) may refer to an instance of an electronic document or data structure, generated for a specific individual (i.e., the credential receiver), and based on a digital credential template. Thus, a digital credential document or data structure may be based on a corresponding digital credential template, but may be customized and populated with user-specific information such as individual identification data (e.g., name, email address, and other user identifiers), credential issuance data (e.g., issue date, geographic location of issuance, authorized issuer of the credential, etc.), and links or embedded data that contain the specific user's supporting documentation or evidence relating to the credential);
displaying the received curriculum vitae interface on a display of the first device; (Interfaces are taught throughout Mercury, see at least para 0033, FIGS. 30A and 30B are screenshots depicting example of different user interface views for displaying a user's badge resume;
receiving a user input on the plurality of records on the first device to update the curriculum vitae items data in the form; (user input devices are taught throughout Mercury, see at least Mercury, para 0092, teaching user interface input devices; para 0107, The digital credential receiver system may be a computing device associated with a credential receiver (or credential earner), for example, an individual user of an electronic learning system, professional training system, online certification course, etc. ... credential receivers may access the platform server via systems to accept or reject newly issued digital credentials, review and update previously earned digital credentials);
transmitting, by the first device, a first completion request directed to the internal training and the updated curriculum vitae items data to the cloud server; (Mercury, para 0112, teaches transmitting/receiving digital credential templates and digital credentials, digital credential data requests/responses to the platform server; para 0142, user's work-related activities and tasks performed/completed);
after receiving the transmitted first completion request and the updated curriculum vitae items data from the first device, determined, by the cloud server, whether the permission data in ...; (Mercury, para 0074 and 0078, accounts data store for individual end users, supervisors, administrator users, and entities such as companies or educational institutions; certain users have supervisory access over one or more users);
when the cloud server determines that the permission data in ... , notifying, by the cloud server,the second device and ransmitting to the second device a first checklist form including a first checking and signing field according to the updated curriculum vitae items data; (Mercury, para 0112, security and authentication capabilities, and capabilities for transmitting/receiving digital credential templates and digital credentials, digital credential data requests/responses to the platform server; para 0211, evidence files and authentication data (e.g., signature files collected during testing, biometric data, etc.));
displaying the first checklist form on a display of the second device; (Displaying data is taught throughout Mercury, see at least para 0054, teaching user devices and supervisor devices may display content received via the content distribution network, and may support various types of user interactions with the content);
receiving, by the second device, a first digital seal entered by the second device to audit and sign the first curriculum vitae item inthe first checklist form; (Mercury, para 0112, security and authentication capabilities, transmitting/receiving digital credential templates and digital credentials, digital credential data requests/responses to the platform server; para 0142, user's work-related activities and tasks performed/completed; para 0029, FIG. 26 a blockchain record of issued badges);
receiving and storing, by the cloud server, the audited first checklist form transmitted from the second device; (See at least Mercury, para 0063, devices on a web-based or cloud-based service; Storing data is throughout Mercury, see at least para 0005 and Figure 3);
after receiving the audited first checklist form from the second device, transmitting, by thefirst device: a second completion request to the cloud server; (Mercury, para 0142, user's work-related activities and tasks performed/completed; para 0112, teaches transmitting/receiving digital credential templates and digital credentials, digital credential data requests/responses to the platform server);
when the cloud server receives the second completion request from the first device, notifying, by the cloud server,the third deviceand transmitting to the third device a second checklist form including a second checking and signing field according to the updated curriculum vitae items data;(Mercury, para 0112, security and authentication capabilities, transmitting/receiving digital credential templates and digital credentials, digital credential data requests/responses to the platform server; para 0142, user's work-related activities and tasks performed/completed; para 0029, FIG. 26 a blockchain record of issued badges);
receiving, by the third device, a second digital seal entered by the third user to audit and sign the second curriculum vitae item inthe second checklist form; (Mercury, para 0112, security and authentication capabilities, transmitting/receiving digital credential templates and digital credentials, digital credential data requests/responses to the platform server; para 0142, user's work-related activities and tasks performed/completed); para 0029, FIG. 26 a blockchain record of issued badges).
receiving and storing, by the cloud server, the audited second checklist form transmitted from the third device (See at least Mercury, para 0063, devices on a web-based or cloud-based service; Storing data is throughout Mercury, see at least para 0005 and Figure 3).
Yet, Mercury does not appear to explicitly teach and in the same field of endeavor Apps teaches determining the second client information is superior than the permission data in the first client information (Apps, para 00101, a software based organizational hierarchy system across multiple online organizational charts including establishing thresholds and permissions; para 0047, teaches an organizational chart application including application programming interfaces permitting such exchange, which are numerous, and other cloud-based computing services and utilities, such as Google™, Facebook™, Linkedln™, Twitter™, Salesforce .com , DropBox.com , and others).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Mercury with the second client information is superior than the permission data in the first client information as taught by Apps with the motivation to generate an electronic organizational chart (Apps, Abstract). The Mercury invention now incorporating the Apps invention, has all the limitations of claim 1.
Regarding Claim 3, Mercury, now incorporating Apps, teaches The method for providing portable curriculum vitae of Claim 1,further comprising recording, by the first device,in the curriculum vitae items data (Mercury, para 0084 and 0106, courses or curriculums in training or educational contexts, user data such as associated content compilations or programs, content completion status, user goals, results, and the like.)
Regarding Claim 4, Mercury, now incorporating Apps, teaches The method for providing portable curriculum vitae of Claim 1, wherein, a public key infrastructure (PKI) is used for the first digital seal and the second digital seal (Mercury, para 0188, blockchain may use encryption technology, including public and private keys).
Regarding Claim 5, Mercury, now incorporating Apps, teaches The method for providing portable curriculum vitae of Claim 1, wherein, the curriculum vitae items data includes at least one work item record, at least one academic record, one educational level, one major subject, one industry sector of former jobs, one title of former jobs, one personal expertise, one professional certification, one language ability or a combination of two or more conditions (Mercury, para 0198, a user's resume and badge portfolio may include education-based and skills-based badges, professional credentials, personality badges, DNA-based badges, health-based or fitness-based badges, etc.).
Regarding Claim 6, Mercury, now incorporating Apps, teaches The method for providing portable curriculum vitae of Claim 1, wherein, the curriculum vitae items data is transmitted and accessed between the first client and the cloud server via a block chain technology; the second client and the third client audit and sign the data via the block chain technology (Mercury, para 0184, digital credentialing systems described herein may be implemented using blockchain technology. For example, a distributed network of badge owners, badge issuers, badge earners, and others may collaborate via a badging network to verify and maintain a badge blockchain)
Regarding Claim 7, the claim is an obvious variant to claim 1 above, and is therefore rejected on the same premise. Mercury further teaches a system (System is taught throughout Mercury, see at least Mercury, para 0009, a digital credential system).
Regarding Claim 9, Mercury, now incorporating Apps, teaches The system for providing the portable curriculum vitae of Claim 7, wherein, the first client further records a time length, a work proceeding, a completion status, or any combination thereof in connection with all the work items to the cloud server at the same time (Mercury, para 0084 and 0106, courses or curriculums in training or educational contexts, user data such as associated content compilations or programs, content completion status, user goals, results, and the like.)
Regarding Claim 10, Mercury, now incorporating Apps, teaches The system for providing the portable curriculum vitae of Claim 7, wherein, a public key infrastructure (PKI) is used for the digital seal (Mercury, para 0188, blockchain may use encryption technology, including public and private keys).
Regarding Claim 11, Mercury, now incorporating Apps, teaches The system for providing the portable curriculum vitae of Claim7, wherein, the curriculum vitae items data includes at least one work item record, at least one academic record, one educational level, one major subject, one industry sector of former jobs, one title of former jobs, one personal expertise, one professional certification, one language ability or a combination of two or more conditions (Mercury, para 0198, a user's resume and badge portfolio may include education-based and skills-based badges, professional credentials, personality badges, DNA-based badges, health-based or fitness-based badges, etc.).
Regarding Claim 12, Mercury, now incorporating Apps, teaches The system for providing the portable curriculum vitae of Claim 7, wherein, the curriculum vitae items data is transmitted and accessed between the first client and the cloud server via a block chain technology; the second client and the third client audit and sign the first curriculum vitae item and the second curriculum vitae item via the block chain technology; the curriculum vitae items data, the first digital seal and the second digital seal are transmitted between cloud server via the block chain technology (Mercury, para 0184, digital credentialing systems described herein may be implemented using blockchain technology. For example, a distributed network of badge owners, badge issuers, badge earners, and others may collaborate via a badging network to verify and maintain a badge blockchain)
Additional Prior Art Consulted
The prior art made of record and not relied upon which is considered pertinent to applicant’s disclosure includes the following:
Tummuru US 11,170,346 B2 - A credentials verification network utilizes blockchain technology to track/verify credentials for candidates that can later be used in the hiring verification process. As implemented by nodes of a distributed network, a candidate receives from a first network node a secure credential generated by a credentialing source from an original credential document. The first node processes the secure credential according to a security feature (e.g., hash function) to create a transaction, and assigns an identifier to the transaction. The first node signs the transaction with a private key to create a transaction signature. The first node sends the signed transaction to a central server that broadcasts the transaction to the blockchain network. Once the network has accepted the transaction, the candidate will be notified and handed over the raw text document and transaction receipt ID. The candidate can forward the information to a recruiter or potential employer running a second node.
Wandmacher et al. US 6,990,465 B1 - The present invention relates generally to education or learning system implemented via a communication network and, in particular, for a system for using a vendor certification program offered via a communication network.
Applicant is advised to review additional references supplied on the PTO-892 as to the state of the art of the invention.
Response to Arguments
Applicants arguments filed on 08/04/2025 have been fully considered but they are not persuasive.
Regarding 35 U.5.C. § 101 rejections: Examiner has updated the 101 rejection in light of the most recent claim amendments and maintains the 101 rejection. Applicant’s arguments have been fully considered but are found unpersuasive. With respect to Applicants remarks “In particular, claims 1 and 7 each recite the structures of the first, second and third devices as well as the cloud server and communications between these devices. Claims 1 and 7 also recites transmitting various forms to the devices for receiving information for updates and audits. Therefore, claims 1 and 7, and their dependent claims, are not directed to the abstract idea and thus patent eligible.” Examiner respectfully notes Applicant appears to be confusing the 101 analysis. With respect to Applicant’s remarks – “the first, second and third devices as well as the cloud server... are not directed to the abstract idea” – additional elements are considered in Step 2A Prong Two and Step 2B of the analysis, not under Step 2A Prong One.
Further, with respect to Applicant’s remarks “It improves the way companies review applicants' work histories and strengthens the authenticity of employment records.” Examiner respectfully does not find these assertions persuasive because Applicant does not explain how or why any limitations of the claims are a technical improvement to a computer or another technology or technical field. As such, Examiner finds Applicant's arguments fail to comply with 37 CFR 1.111 because they amount to a general allegation that the claims define a patent eligible invention without specifically pointing out how the language of the claims reflect a practical application (e.g., how the claims reflect an improvement). In summary, the computer is merely a platform on which the abstract idea is implemented. Simply executing an abstract concept on a computer does not transform a patent-ineligible claim into a patent-eligible one. There are no improvements to another technology or technical field, no improvements to the functioning of the computer itself, transformation or reduction of a particular article to a different state or thing or any other meaningful limitations beyond generally linking the use of an abstract idea to a particular technological environment as a result of performing the claimed method. Hence the claims do not recite significantly more than an abstract idea. Therefore, Applicants remarks are found unpersuasive and Examiner maintains the 101 rejection with respect to these and all depending claims unless otherwise indicated.
Regarding 35 U.S.C. § 103 rejections. Examiner has updated the prior art rejections with newly applied teachings of the Mercury reference. See above rejection and at least Mercury Figures 26-27; para 0029-0030 and para 0198. With respect to the prior art rejections and Applicants arguments, these arguments have been given due consideration but they are moot in view of the newly applied teachings of the references as described above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to REBECCA R NOVAK whose telephone number is (571)272-2524. The examiner can normally be reached Monday - Friday 8:30am - 5:00pm EST.
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, Lynda Jasmin can be reached at (571) 272-6782. 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.
/R.R.N./Examiner, Art Unit 3629
/LYNDA JASMIN/Supervisory Patent Examiner, Art Unit 3629